Dave Korn writes: > On 26 October 2007 17:11, Andrew Haley wrote: > > > > 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. > > Well, that's the bone of contention. I suggest that you cannot > infer "counter is not accessed" when the condition is false, > according to the C language spec, because there are two different > semantics of the word "accessed" here: as-if accessed, as per the > ideal machine definition of C, and actually accessed, as in what > actually happens in the underlying code. The C standard only makes > guarantees about the as-if accesses.
That's right: the problem is that POSIX threads makes assumptions that the C standard does not guarantee. This is why I said previously "The problem with your argument is that you're looking at ISO C but not at POSIX threads." POSIX threads requires more than just strict ISO as-if semantics. > > According to POSIX we do not have to declare > > volatile memory that we only access when we hold a mutex. > > Is the problem that POSIX doesn't make the distinction between > as-if and actual behaviour that is such an essential part of the C > standard? POSIX introduces extra requirements that are not part of the C standard. This is one of them. Unfortunately it does so in a more-or-less informal way. > > This introduces a data race that is not in the user's program. > > Do you mean that it's not in the as-if idealised version of the > program that the compiler constructs, or that it's not in the > high-level source? The program actually requires not just Standard C but Standard C + POSIX threads. In other words, you cannot optimize POSIX threads programs in the same way that you optimize single-threaded progarms. This argument is the subject of Hans Boehm's paper "Threads cannot be implemented as a library", referenced above. Andrew.
