On 10/26/07, Andrew Haley <[EMAIL PROTECTED]> wrote: > Dave Korn writes: > > On 26 October 2007 16:27, Andrew Haley wrote: > > > > > Dave Korn writes: > > > > On 26 October 2007 15:59, Ian Lance Taylor wrote: > > > > > > > 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. > > > > Perhaps I've jumped into the wrong one of the two near-identical > > threads we have going on this, but my understanding of the original > > complaint was that gcc writes to the variable regardless of whether > > it needs an update or not, and that this is a problem in the case > > where one thread is accessing *without* using the mutex that the > > other one *is* using. > > No, that is not the problem. > > The problem is code like this: > > int counter; > > ... > > if (we_hold_counters_mutex) > counter++; > > This is legal POSIX threads code: counter is not accessed when we do > not hold the mutex. According to POSIX we do not have to declare > volatile memory that we only access when we hold a mutex.
I hope we're not trying to support such w/o volatile counter. Whatever POSIX says, this would pessimize generic code too much. Richard.
