"memory" clobber in synchronization primitives

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

It should be well-specified which operations are guaranteed to be memory
barriers and the set should be consistent across all the ports.

As I said, most ports now have a barrier in `testandset', but x86 does not.
Some of the i486 and m68k <atomicity.h> functions use "memory" clobbers,
but those look like hacks around incorrectly specified outputs in those
asms, rather than attempts to provide explicit global memory barriers.
(The right thing to do in those cases is extra output specs for %N numbers
that never appear in the asm code string, or appear only in a comment
therein.  Note you can do this even for variable-sized outputs (e.g. string
fns), with a construct like `"=m" (*((struct {char _s[N];} *) S))' for some
pointer S and byte-length N.)

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.  Since (at least in GCC)
any normal function call is a global memory barrier, it may arise seldom
enough to be subtle and unclear.  The pthreads synchronization primitives
in linuxthreads are all implemented as normal functions (not macros or
inlines), so the question has not yet had to be answered.