Re: [patch 1/3] mutex subsystem: trylock

[Ingo Molnar <mingo@elte.hu>]

* Ingo Molnar <mingo@elte.hu> wrote:

> * Nicolas Pitre <nico@cam.org> wrote:
> 
> > > here we go to great trouble trying to avoid the 'slowpath', while we 
> > > unconditionally force the next unlock into the slowpath! So we have 
> > > not won anything. (on a cycle count basis it's probably even a net 
> > > loss)
> > 
> > I disagree.  [...elaborate analysis of the code ...]
> 
> you are right, it should work fine, and should be optimal. I'll add 
> your xchg variant to mutex-xchg.h.

the patch below adds it, and it boots fine on x86 with mutex.c hacked to 
include asm-generic/mutex-xchg.h.

	Ingo

Index: linux/include/asm-generic/mutex-xchg.h
===================================================================
--- linux.orig/include/asm-generic/mutex-xchg.h
+++ linux/include/asm-generic/mutex-xchg.h
@@ -82,7 +82,25 @@ do {									\
 static inline int
 __mutex_fastpath_trylock(atomic_t *count, int (*fn)(atomic_t *))
 {
-	return fn(count);
+	int prev = atomic_xchg(count, 0);
+
+	if (unlikely(prev < 0)) {
+		/*
+		 * The lock was marked contended so we must restore that
+		 * state. If while doing so we get back a prev value of 1
+		 * then we just own it.
+		 *
+		 * [ In the rare case of the mutex going to 1 and then to 0
+		 *   in this few-instructions window, this has the potential
+		 *   to trigger the slowpath for the owner's unlock path, but
+		 *   that's not a problem in practice. ]
+		 */
+		prev = atomic_xchg(count, -1);
+		if (prev < 0)
+			prev = 0;
+	}
+
+	return prev;
 }
 
 #endif