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

[Nick Piggin]

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 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/