http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39612
--- Comment #17 from Zdenek Dvorak <rakdver at gcc dot gnu.org> 2012-01-17
11:01:45 UTC ---
> > LSM will move inter[1] to a temporary variable regardless of the locks,
> > which
> > will cause race conditions with other threads (and whether loop header is
> > copied or not is irrelevant).
>
> I think for the explicit lock code we are safe because we consider
> the lock/unlock calls to alias inter[] so we cannot SM it.
This is not necessary to be the case, if you for some reason implement your own
version of locking (and especially if lock/unlock get inlined). Still, this
probably would not happen in practice.
> In the
> light of the C++11 memory model we probably have to do something
> about even non-volatile accesses.
>
> I suppose we cannot easily detect at the moment if the loop has
> its header copied, thus, is do {} while style? We're using
> ref_always_accessed_p for the trapping insns issue, we could
> extend that to cover all global memory accesses - but I suppose
> that would pessimize things if ref_always_accessed_p isn't
> very good.
Having header copied or not is actually irrelevant for the problem in question.
You will get the same thing in
do
{
if (maybe)
inter[1] = bla;
}
while (something);
So, extending the use of ref_always_accessed_p would be the thing you want to
do; probably not by default, since this only affects badly written (no
volatile) multithreaded programs, but having that option could be useful
(of course, this should be on by default for c++, if it is the required
behavior).
