lkml.org 
[lkml]   [2005]   [Dec]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
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 <nickpiggin@yahoo.com.au> wrote:
>>>
>>>
>>>
>>>>It would be nice to first do a run with a fair implementation of
>>>>mutexes.
>>>
>>>
>>>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
demonstrated.

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 http://au.messenger.yahoo.com

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

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