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.
gcc turns this code into
tmp = counter;
if (we_hold_the_counters_mutex)
tmp++;
counter = tmp;
This introduces a data race that is not in the user's program.
Andrew.
