[lkml]   [2005]   [Dec]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [patch 0/8] mutex subsystem, ANNOUNCE
Arjan van de Ven wrote:
> On Thu, 2005-12-22 at 18:56 +1100, Nick Piggin wrote:
>>Ingo Molnar wrote:
>>>* Nick Piggin <> wrote:
>>>>It would be nice to first do a run with a fair implementation of
>>>which fairness implementation do you mean - the one where all tasks will
>>>get the lock in fair FIFO order, and a 'lucky bastard' cannot steal the
>>>lock from waiters and thus put them at an indefinite disadvantage?
>>I guess so. I'm not so worried about the rare 'lucky bastard' ie. a
>>lock request coming in concurrently, but rather the naturally favoured
>>'this CPU' taking the lock again after waking up the head waiter but
>>before it gets a chance to run / transfer the cacheline.
> that's just the most evil lucky bastard....

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

Which might be the right thing to do, but having the front waiter go to
the back of the queue I think is not.

SUSE Labs, Novell Inc.

Send instant messages to your online friends

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-12-22 09:13    [W:0.071 / U:2.348 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site