[Omp] OpenMP spec 2.5 seems to have incorrect flush example on page 12

[Greg Bronevetsky]

I disagree that the programmer should be on their own regarding
optimizations to functions that may be called from inside a parallel
region. You can take Marcel's example and put it into a function and then
the compiler can just inline it and perform the invalid optimization. I
think that if you're using OpenMP, all code needs to be compiler in a
thread-safe manner unless it can be shown that it is never executed during
a parallel region. This should apply to any linked libraries. However, if
you only mean that it is the programmer's responsibility to link to
thread-safe libraries, then I agree.

As for the spec forbidding specific optimizations, that's not necessary.
The spec (both 2.5 and the formal model) already forbids the optimization
that we've been discussing. The focus of the discussion was on exactly
what was happening and whether we want the spec to forbid it. We figured
it out and the answer is "yes".

                             Greg Bronevetsky

On Tue, 8 May 2007, Federico Massaioli wrote:

> On Mon, 7 May 2007, Greg Bronevetsky wrote:
> 
> > My point is that the implicit flushes do not avoid this problem if that
> > compiler optimization is used. I agree that it is not threadsafe but I
> > didn't want to make a stand because I wanted to see what other people's
> > thoughts. Your "final comment" section summarizes pretty well why this
> > should be declared uniformly illegal.
> 
> I'm not sure I correctly understand your question, but I think that if the 
> compiler adds instructions which break the clear programmer intent in a 
> parallel region, like hoisting in a register a shared variable used in a 
> parallel region for inter-threads communication, even with a simple:
> r = X;
> X = r;
> without respecting the implicit and explicit flushes on X I've put in the 
> code, I think the compiler is broken.
> 
> If however the code is in a separate function, which can be called inside 
> or outside an active parallel region, I'm glad to be on my own, and take 
> the responsibility to specify the appropriate optimization options to the 
> compiler.
> 
> But in general, I think that explicitly forbidding some optimizations in 
> the specs would be counterproductive. It would be too restrictive, and the 
> list would never be exhaustive.
> 
> FWIW
> Federico
> 
> -----------------------------------------------------------------------
> "Even if you don't always actually 'need' the highest precision, you
>   can still delight in the joy of fully understanding what's going on."
>               Paul Horowitz & Winfield Hill - The Art of Electronics
> -----------------------------------------------------------------------
> Federico Massaioli                          CASPUR
> email: federico.massaioli at caspur.it         V. dei Tizii 6/b
> Ph.: +39-06-44486710                        I-00185 Roma Italy
> Fax: +39-06-4957083                         www.caspur.it
>