Dave Korn writes: > On 26 October 2007 15:59, Ian Lance Taylor wrote: > > > Andreas Schwab <[EMAIL PROTECTED]> writes: > > > >> Ian Lance Taylor <[EMAIL PROTECTED]> writes: > >> > >>> The above code happens to use pthread_mutex_trylock, but there is no > >>> need for that. > >> > >> pthread_mutex_trylock is special, because POSIX says it is a memory > >> synchronisation point (see section 4.10 Memory Synchronization). > > > > Sure. But the argument that gcc is doing something wrong stands up > > just fine even we just test a global variable. The argument that gcc > > is doing something wrong does not rely on the fact that the function > > called is pthread_mutex_trylock. > > Indeed; as I understand it, what the argument that gcc is doing > something wrong relies on is the incorrect assumption that *all* > variables ought to behave like volatile ones, i.e. have an exact > one-to-one relationship between loads and stores as written in the > HLL and actual machine load/store operations.
No, it doesn't, it relies on the fact that POSIX allows shared access to non-volatile memory as long as mutexes are used to enforce mutual exclusion. POSIX does not require memory used in such a way to be declared volatile. The problem with your argument is that you're looking at ISO C but not at POSIX threads. The new C++ threads memory model is intended by its authors to solve this mess. Andrew.