This is the mail archive of the libc-hacker@sourceware.cygnus.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: "memory" clobber in synchronization primitives


> Date: Mon, 31 Aug 1998 15:04:36 -0400
> From: Roland McGrath <roland@frob.com>

> In the linuxthreads pt-machine.h file, the alpha, powerpc, and mips
> definitions of `testandset' use a "memory" clobber in addition to their
> output specs in their GCC `asm', but the i386 definition does not.  This
> acts as a "memory barrier" to the optimizer, so that after the
> synchronization primitive, the compiler knows that memory might have
> changed.  This allows code using these primitives to robustly access shared
> data structures whose writing is synchronized this way, without using
> `volatile' or explicit barriers of its own (i.e. `asm("":::"memory");').
> 
> What is the general opinion on this?

Well, I took testandset out of the ppc port, because it was never
used.  However, a similar argument applies to compare_and_swap.

On ppc, arguably no such clobber is required, because anyone who
expects memory ordering between threads has to use a 'sync'
instruction anyway.  The actual compare_and_swap procedure has two
'sync' instructions surrounding the main code, which are 'asm
volatile' and therefore memory barriers.

I believe that the inline asm should be in fact using a 'Q'
constraint.  I will change this now that I know how---the trick is to
write '%P1' for the operand.

> It is not particularly clear to me from 1003.1-1996 whether
> pthread_mutex_lock et al are expected to be explicit memory barriers
> obviating the need for `volatile'-qualified reads.

Note that on ppc, 'volatile' is not at present sufficient for
multiprocessor synchronization.  Arguably, this should be fixed in
egcs---certainly it would make the embedded people happy.

-- 
Geoffrey Keating <geoffk@ozemail.com.au>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]