[PATCH?] Separate pthread patches, #2 take 3

Dave Korn dave.korn.cygwin@googlemail.com
Thu Jun 4 02:51:00 GMT 2009

Christopher Faylor wrote:

> I thought that, given your last message to cygwin-developers, you were
> going to go off and figure out the best of four implementations.  Is this
> the result of that investigation?

  Once I discarded the ones that weren't quite right because they included a
setz/sete instruction (bsd and boehm), I was left with the ones in the
attached testcase.  The only version I hadn't tested yet is the linux-derived one:

struct __xchg_dummy { unsigned long a[100]; };
#define __xg(x) ((struct __xchg_dummy *)(x))
#define LOCK_PREFIX " lock "
static inline unsigned long __cmpxchg(volatile void *ptr, unsigned long old,
				      unsigned long newv)
	unsigned long prev;
		__asm__ __volatile__(LOCK_PREFIX "cmpxchgl %1,%2"
				     : "=a"(prev)
				     : "q"(newv), "m"(*__xg(ptr)), "0"(old)
				     : "memory");
		return prev;
extern __inline__ long
ilockcmpexch (volatile long *t, long v, long c)
  return __cmpxchg (t, c, v);

  This actually produces the same assembly as my version:

	movl	__ZN13pthread_mutex7mutexesE, %eax	 # mutexes.head, D.2029
	movl	%eax, 36(%ebx)	 # D.2029, <variable>.next
 # 75 "mxfull.cpp" 1
	 lock cmpxchgl %ebx,__ZN13pthread_mutex7mutexesE	 # this,
 # 0 "" 2
	cmpl	%eax, 36(%ebx)	 # prev, <variable>.next
	jne	L14	 #,

but it's a horrible bit of code.  Declaring the memory location as input only,
then clobbering all of memory and potentially confusing the optimisers with
type aliasing casts?  It makes me very uneasy.


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: mxfull.cpp
URL: <http://cygwin.com/pipermail/cygwin-patches/attachments/20090604/105dcd2e/attachment.ksh>

More information about the Cygwin-patches mailing list