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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
