[patch 0/9] mutex subsystem, -V4

From: Ingo Molnar
Date: Thu Dec 22 2005 - 06:41:50 EST


this is the -V4 of the mutex subsystem patch-queue. It consists of the
following patches:

add-atomic-xchg.patch
add-atomic-call-func-i386.patch
add-atomic-call-func-x86_64.patch
add-atomic-call-wrappers-rest.patch
mutex-core.patch
mutex-switch-arm-to-xchg.patch
mutex-debug.patch
mutex-debug-more.patch
xfs-mutex-namespace-collision-fix.patch

the patches are against Linus' latest GIT tree, and they should work
fine on every Linux architecture.

Changes since -V3:

- imlemented an atomic_xchg() based mutex implementation. It integrated
pretty nicely into the generic code, and most of the code is still
shared.

- added __ARCH_WANT_XCHG_BASED_ATOMICS: if an architecture defines
this then the generic mutex code will switch to the atomic_xchg()
implementation.

This should be conceptually equivalent to the variant Nicolas Pitre
posted - Nicolas, could you check out this one? It's much easier to
provide this in the generic implementation, and the code ends up
looking cleaner.

- eliminated ARCH_IMPLEMENTS_MUTEX_FASTPATH: there's no need for
architectures to override the generic code anymore, with the
introduction of __ARCH_WANT_XCHG_BASED_ATOMICS.

- ARM: enable __ARCH_WANT_XCHG_BASED_ATOMICS.

- ARM buildfix: move the new atomic primitives to the correct place.
(Nicolas Pitre)

- optimization: unlock the mutex outside of the spinlock (suggested by
Nicolas Pitre)

- removed leftover arch_semaphore reference from the XFS patch. (noticed
by Arjan van de Ven)

- better document the fact that mutex_trylock() follows spin_trylock()
semantics, not sem_trylock() semantics.

- cleanup: got rid of the MUTEX_LOCKLESS_FASTPATH define. (in -V3 this
became equivalent to DEBUG_MUTEXES, via the elimination of the
__HAVE_ARCH_CMPXCHG dependency on the fastpath.)

- further simplified and unified mutex_trylock().

- DocBook entries, and more documentation of internals.

- dropped the spinlock-debug fix, Linus merged it.

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/