[Omp] Two simpler examples (Re: OpenMP spec 2.5 seems to have incorrect flush example on page 12)

[Greg Bronevetsky]

I don't think that your examples are fundamentally scary if we think of it
as follows. The application contains what looks like a race. In this case
the compiler performs a transformation to one of the pieces of code
involved in the race. If the race actually happened, everything would be
fine because the result would be undefined and the transformation would be
correct. However, as it turns out, this piece of code is never executed
(and so, no race), but the compiler-inserted code is still executed,
creating a strange result.

So here's the question for us: if a given piece of code exists in the
source code, does it matter if it is never executed? For example, should
the flush in the following code have any effect on possible reorderings?
   A=1
   if(0) { #pragma omp flush }
   B=2 
In the case of a flush, the spec seems to say yes, since it talks about
statements in the code, rather than statements that may be executed. In
Marcel's example we have code that will not be executed that does not
contain a flush. Do we treat it as code that may execute and say that the
result is undefined because it may be a race or do we only worry about
races that can happen in actual executions?

If we take the former approach, your example 1 would have an undefined
result, while example 2 would have to print 42. If we take the latter
approach, both examples must print 42. I don't know which is better but I
don't think the spec addresses this issue.

                             Greg Bronevetsky

On Sat, 5 May 2007, Yuan Lin wrote:

> Folks, I have no intention to hijack the discussion. But it seems the  
> following two very basic examples may not work as expected under the  
> current specification.
> 
> S is not volatile.
> 
> 
> 
> Example 1
> =========
> 
> t1 :                       t2:
> 
> S = 21;
> 
> barrier 1                  barrier 1
> 
> if (some_false_cond) {     S = 42;
>     S = something
> }
> 
> barrier 2                  barrier 2
> 
> print S;
> 
> 
> Expectation: t1 always prints out 42.
> 
> But t1 may print out 21, as we previous discovered.
> 
> 
> 
> Example 2
> =========
> 
> t1 :                      t2:
> 
> S = 21;
> 
> barrier 1                barrier 1
> 
>                           S = 42;
> 
> barrier 2                barrier 2
> 
> print S;
> 
> 
> Expectation: t1 always prints out 42.
> 
> But t1 may print 21 if the compiler inserts code like
> r = S;
> S = r;
> between the two barriers in thread t1.
> 
> I am not sure about Example 2 (which can be really scary), though the  
> spec seems to allow the transformation.
> 
> 
> Regards,
> 
> -- Yuan
> 
> _______________________________________________
> Omp mailing list
> Omp at openmp.org
> http://openmp.org/mailman/listinfo/omp
>