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

[Nick Piggin]

Arjan van de Ven wrote:
> On Thu, 2005-12-22 at 18:56 +1100, Nick Piggin wrote:
>
> > Ingo Molnar wrote:
> >
> > > * Nick Piggin <nickpiggin@xxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/