Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation

[Nick Piggin <nickpiggin@yahoo.com.au>]

David Howells wrote:
> Arjan van de Ven <arjan@infradead.org> wrote:
>
>
> > > given that
> > > mutex_down() is slightly more costly than current down(), and mutex_up() is
> > > appreciably more costly than current up()?
> >
> > that's an implementation flaw in the current implementation that is not
> > needed by any means and that Ingo has fixed in his version of this
>
>
> As do I. I wrote it yesterday with Ingo looking over my shoulder, as it were,
> but I haven't released it yet.
>
> What I provided was a base implementation that anything can use provided it
> has an atomic op capable of exchanging between two states, and I suspect
> everything that can do multiprocessing has - if you can do spinlocks, then you
> can do this. I ALSO provided a mechanism by which it could be overridden if
> there's something better available on that arch.
>
> As I see it there are four classes of arch:
>
>  (0) Those that have no atomic ops at all - in which case xchg is trivially
>      implemented by disabling interrupts, and spinlocks must be null because
>      they can't be implemented.
>
>  (1) Those that only have a limited exchange functionality. Several archs do
>      fall into this category: arm, frv, mn10300, 68000, i386.
>
>  (2) Those that have CMPXCHG or equivalent: 68020, i486+, x86_64, ia64, sparc.
>
>  (3) Those that have LL/SC or equivalent: mips (some), alpha, powerpc, arm6.

cmpxchg is basically exactly equivalent to a store-conditional, so 2 and 3
are the same level.

I don't know why you don't implement a "good" default implementation with
atomic_cmpxchg.

--
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/