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

From: Nick Piggin
Date: Thu Dec 15 2005 - 20:53:39 EST


David Howells wrote:
Arjan van de Ven <arjan@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/