Re: [patch 0/8] mutex subsystem, ANNOUNCE

[Nick Piggin <nickpiggin@yahoo.com.au>]

Arjan van de Ven wrote:
>>I'd probably just call "bastard": it is probably _unlucky_ when _doesn't_
>>get to retake the lock, judging by the factor-of-4 speedup that Jes
>>demonstrated.
> 
> 
> I suspect that's more avoiding the double wakeup that semaphores have
> (semaphores aren't quite fair either)
> 

It would be great if that were the case.

> 
>>Which might be the right thing to do, but having the front waiter go to
>>the back of the queue I think is not.
> 
> 
> afaik that isn't happening though.
> 

AFAIKS it does.

Failed lockers will go through to __mutex_lock_nonatomic, which calls
__mutex_lock_common to queue it on the tail of the FIFO list race-free.

__mutex_lock_nonatomic then sleeps, waiting for the task to become head
of the list and be worken up.

__mutex_lock_nonatomic then removes this task from the FIFO and calls
__mutex_lock_common again.

If I read right, not only is it a fairness problem, but it could also
harm performance because it will cycle through all waiting tasks rather
than just the next one to go.

If I don't read right... can you explain how it works? :P

-- 
SUSE Labs, Novell Inc.

Send instant messages to your online friends http://au.messenger.yahoo.com