Re: [patch 00/15] Generic Mutex Subsystem

[Benjamin LaHaise <bcrl@kvack.org>]

On Mon, Dec 19, 2005 at 11:11:03AM -0800, Linus Torvalds wrote:
> On Mon, 19 Dec 2005, Ingo Molnar wrote:
> > 
> > in fact, generic mutexes are _more_ fair than struct semaphore in their 
> > wait logic. In the stock semaphore implementation, when a waiter is 
> > woken up, it will retry the lock, and if it fails, it goes back to the 
> > _tail_ of the queue again - waiting one full cycle again.
> 
> Ingo, I don't think that is true.
> 
> It shouldn't be true, at least. The whole point with the "sleeper" count 
> was to not have that happen. Of course, bugs happen, so I won't guarantee 
> that's actually true, but ..

The only thing I can see as an improvement that a mutex can offer over 
the current semaphore implementation is if we can perform the same 
optimization that spinlocks perform in the unlock operation: don't use 
a locked, serialising instruction in the up() codepath.  That might be 
a bit tricky to implement, but it's definately a win on the P4 where the 
cost of serialisation can be quite high.

> [ Oh.  I'm looking at the semaphore code, and I realize that we have a 
>   "wake_up(&sem->wait)" in the __down() path because we had some race long 
>   ago that we fixed by band-aiding over it. Which means that we wake up 
>   sleepers that shouldn't be woken up. THAT may well be part of the 
>   performance problem.. The semaphores are really meant to wake up just 
>   one at a time, but because of that race hack they'll wake up _two_ at a 
>   time - once by up(), once by down().
> 
>   That also destroys the fairness. Does anybody remember why it's that 
>   way? ]

History?  I think that code is very close to what was done in the pre-SMP 
version of semaphores.  It is certainly possible to get rid of the separate 
sleepers -- parisc seems to have such an implementation.  It updates 
sem->count in the wakeup path of __down().

		-ben
-- 
"You know, I've seen some crystals do some pretty trippy shit, man."
Don't Email: <dont@kvack.org>.