Re: Optimization of conditional access to globals: thread-unsafe?

[Michael Matz <matz at suse dot de>]

Hi,

On Sun, 28 Oct 2007, Mark Mielke wrote:

> are not like this. Most uses require only lose ordering. The lose 
> ordering is providing by a mutex or other synchronization primitive. As 
> any function call might call a synchronization primitive, this would 
> mean that any function call should ensure that all scheduled reads or 
> writes to shared data before the function is called, be performed before 
> the function is called. Similarly, all such data may have changed by the 
> time the function returns. Unless the function can be proven to have no 
> effect (global optimization analysis? function inlining?), this is 
> expected behavior.

Yes, and of course GCC doesn't move stores or loads over functions calls.  
That's not the issue at all.  The issue is, that people want to write 
this:

  if (condition)
    *p = value;

(i.e. without any synchronization primitive or in fact anything else after 
the store in the control region) and expect that the store indeed only 
happens in that control region.  And this expectation is misguided.  Had 
they written it like:

  if (condition) {
    *p = value;
    membarrier();
  }

it would have worked just fine.


Ciao,
Michael.