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

From: Ingo Molnar
Date: Tue Dec 13 2005 - 05:37:48 EST



* Ingo Molnar <mingo@xxxxxxx> wrote:

>
> * Ingo Molnar <mingo@xxxxxxx> wrote:
>
> > > Nick Piggin <nickpiggin@xxxxxxxxxxxx> wrote:
> > >
> > > > We have atomic_cmpxchg. Can you use that for a sufficient generic
> > > > implementation?
> > >
> > > No. CMPXCHG/CAS is not as available as XCHG, and it's also unnecessary.
> >
> > take a look at the PREEMPT_RT implementation of mutexes: it uses
> > cmpxchg(), and thus both the down() and the up() fastpath is lockless!
> > (And that is a mutex type that does alot more things, as it supports
> > priority inheritance.)
> >
> > architectures which dont have cmpxchg can use a spinlock just fine.
>
> the cost of a spinlock-based generic_cmpxchg could be significantly
> reduced by adding a generic_cmpxchg() variant that also includes a
> 'spinlock pointer' parameter.
>
> Architectures that do not have the instruction, can use the specified
> spinlock to do the cmpxchg. This means that there wont be one single
> global spinlock to emulate cmpxchg, but the mutex's own spinlock can
> be used for it.
>
> Architectures that have the cmpxchg instruction would simply ignore
> the parameter, and would incur no overhead.

an additional twist: we could add generic_cmpxchg_lock(), which would
return the spinlock locked if the cmpxchg fails. (this is what we want
to do anyway) This way architectures that dont have CMPXCHG would take
the spinlock unconditionally and do the cmp-xchg emulation, while the
other architectures would take it only if the cmpxchg fails.

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