[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:

L14:
	movl	__ZN13pthread_mutex7mutexesE, %eax	 # mutexes.head, D.2029
	movl	%eax, 36(%ebx)	 # D.2029, <variable>.next
/APP
 # 75 "mxfull.cpp" 1
	 lock cmpxchgl %ebx,__ZN13pthread_mutex7mutexesE	 # this,
 # 0 "" 2
/NO_APP
	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.

    cheers,
      DaveK


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