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

[Greg Bronevetsky]

Oh yeah, good point. The barriers in this code clean things up pretty
well. What I said in response to Yan's email only applies to locks,
criticals and ordereds, not barriers.

                             Greg Bronevetsky

On Sat, 5 May 2007, Hoeflinger, Jay P wrote:

> My thoughts:
> 
> Barrier 1 includes a flush that requires the "temporary view" to be
> abandoned.  The temporary view is defined to be caches, registers or
> other local storage.  So, no copy of S ("r=S") can be inserted by the
> compiler before the barrier to hold its value across the barrier,
> because if it did that would change the meaning of the program.
> Likewise, an "r=S" cannot be inserted by the compiler after the barrier
> because that would be inserting a race in the program.  Therefore, the
> optimization we've been talking about is not possible in this case.  
> 
> Likewise, barrier 2 requires the next read of S to come from memory (not
> from any kind of temporary view).
> 
> So, I'm thinking Example 1 can print only 42.
> 
> By the same reasoning, the optimization cannot be used in Example 2.  
> 
> The only possible way to rationalize the optimization in Example 1 that
> I can see is that there's already a possible race in the code, so
> inserting another race wouldn't matter.  But, this doesn't make sense to
> me.  Inserting a race in a program seems to be always wrong.
> 
> Jay
> 
> 
> 
> 
> 
> -----Original Message-----
> From: omp-bounces at openmp.org [mailto:omp-bounces at openmp.org] On Behalf
> Of Yuan Lin
> Sent: Saturday, May 05, 2007 7:58 PM
> To: omp at openmp.org
> Subject: [Omp] Two simpler examples (Re: OpenMP spec 2.5 seems to have
> incorrect flush example on page 12)
> 
> 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
> _______________________________________________
> Omp mailing list
> Omp at openmp.org
> http://openmp.org/mailman/listinfo/omp
>