The big kernel lock strikes again

Posted May 16, 2008 17:48 UTC (Fri) by giraffedata (guest, #1954)
In reply to: The big kernel lock strikes again by k3ninho
Parent article: The big kernel lock strikes again

I can't make my mind up whether comparable systems in real life (e.g. bars or food kiosks) have greater throughput when there's an ordered queue or a mess of people waiting.

How could there possibly be higher throughput with the ordered queue? Because it takes time to figure out who's next in the mess of people? Because that doesn't have an analog in these lock mechanisms.

I suspect that having people wait in line allows them to think of other things and not be ready when their turn comes -- a phenomenon with parallels to the cold caches mentioned above.

This analogy suggests a sophisticated optimal way to address the issue. At the kiosk, I don't think this effect actually happens with the ordered queue because you can see your turn coming up, and you get ready. If a waiter for a lock could, shortly before the lock is available, transform from waiting on a semaphore to spinning, he would be ready to use the lock the moment it becomes available but not be able to jump much ahead of his fair ordering. Now if the dispatcher could just reload caches at each dispatch, it would be great.