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

[Nicolas Pitre <nico@cam.org>]

On Wed, 21 Dec 2005, Ingo Molnar wrote:

> Changes since the previous version:
> 
> - removed the fastpath dependency on __HAVE_ARCH_CMPXCHG: now every 
>   architecture is able to use the generic mutex_lock/mutex_unlock 
>   lockless fastpath. The quality of the fastpath is still as good as in 
>   the previous version.
> 
> - added ARCH_IMPLEMENTS_MUTEX_FASTPATH for architectures that want to 
>   hand-code their own fastpath. The mutex_lock_slowpath,
>   mutex_unlock_slowpath and mutex_lock_interruptible_slowpath global
>   functions can be used by such architectures in this case, and they 
>   should implement the mutex_lock(), mutex_unlock() and
>   mutex_lock_interruptible() functions themselves. I have tested this
>   mechanism on x86. (but x86 wants to use the generic functions 
>   otherwise, so those changes are not included in this patchqueue.)

This is a good step in the right direction for ARM, but not quite there 
yet.

As it is, the core mutex code is still relying on atomic 
decrement/increment to work properly.  What would be extremely 
beneficial on ARM is to be able to use (variants of) atomic_xchg 
everywhere.  And the semantics of a mutex allows that where a semaphore 
doesn't (which is why I see big benefits for ARM with mutexes).

I even forsee a fast path implementation on ARMv6 that would use an 
hybrid approach which will be less instructions and cycles than a 
standard atomic decrement/increment (they are available only on ARM 
version 6 and above).

What we'd need is a bit more  flexibility but only at the low level.  No 
need to reimplement the whole of mutex_lock(), mutex_unlock(), and 
friends.

Please consider the 3 following patches that already bring an immediate 
benefit on ARM, even if the fast path isn't inlined yet.


Nicolas