[Omp] Still on the barrier (fwd)

[James Beyer]

The example you have below is trying to explain how barriers bind to 
their enclosing parallel region.  The test case nesting looks something 
like:
!$ omp parallel
    !$ omp do
        !$ omp parallel
            !$ omp barrier

In this context the barrier binds to nearest parallel region which is a 
NON-worksharing parallel region nested inside of a worksharing parallel 
region.  For implementations which support nested parallel regions each 
thread of the omp-do construct will create a new team of 'n' threads 
when the hit the nested parallel region, for implementations that do not 
support nesting the enclosed parallel-region team will consist of the 
single thread that hits the parallel construct.  These new teams will 
barrier amongst themselves, however, the individual threads from the 
omp-do will not attempt to barrier at that level, as that is not the 
current active construct.  I.E. the barrier was bound to the nested 
parallel region!

I am unsure how well I have explained this.  If someone else can explain 
it better; please do!

james

Shengyan Hong wrote:
> Every OMP member,
>      I read the example A.15 in the spec25.
> Appendix A Examples 141
>       SUBROUTINE WORK(N)
>         INTEGER N
>       END SUBROUTINE WORK
>       SUBROUTINE SUB3(N)
>       INTEGER N
>         CALL WORK(N)
> !$OMP   BARRIER
>         CALL WORK(N)
>       END SUBROUTINE SUB3
>       SUBROUTINE SUB2(K)
>       INTEGER K
> !$OMP   PARALLEL SHARED(K)
>           CALL SUB3(K)
> !$OMP   END PARALLEL
>       END SUBROUTINE SUB2
> SUBROUTINE SUB1(N)
>       INTEGER N
>         INTEGER I
> !$OMP   PARALLEL PRIVATE(I) SHARED(N)
> !$OMP     DO
>           DO I = 1, N
>             CALL SUB2(I)
>           END DO
> !$OMP   END PARALLEL
>       END SUBROUTINE SUB1
>       PROGRAM A15
>         CALL SUB1(2)
>         CALL SUB2(2)
>         CALL SUB3(2)
>       END PROGRAM A15
>       Is the barrier nested in the work sharing region? Is it possible 
> for me to insert a barrier into a barrier by the form above?
>       If I cannot do so, what should I do to test the idle time in a 
> barrier for different threads on different processors? I mention the 
> problem in detail in Sunday's email.
>       Thank you very much.
>
> ---------- Forwarded message ----------
> Date: Mon, 12 Mar 2007 08:25:41 -0500
> From: James Beyer <beyerj at cray.com>
> To: Shengyan Hong <shhong at cse.psu.edu>
> Cc: omp at openmp.org
> Subject: Re: [Omp] Still on the barrier
>
> Shengyan Hong wrote:
>>       Since you tell me that barrier can not be added into the 
>> parallel region. Now can you tell me where I can add the barrier. I 
>> think that the place of the code should have 8 threads. Right? To the 
>> end, how can I use barrier in the fortran code? Thank you very much.
>>                                               Shengyan Hong
>> _______________________________________________
>> Omp mailing list
>> Omp at openmp.org
>> http://openmp.org/mailman/listinfo/omp
>>
> Just to be clear, no one has said you can not put a barrier in a 
> parallel region.  What has been stated is that barriers may not be 
> placed in work sharing constructs.  There are at least two types of 
> parallel regions, redundant and work sharing.  Barriers are properly 
> defined in redundant code as there is a reasonable guarantee that 
> every thread in the team will hit the same barrier.  In a work sharing 
> construct like a "parallel do" does the exact opposite of a redundant 
> region.  It ensures that no two threads will ever execute the same 
> iteration of a loop which means that barriers inside of the loop will 
> not have the same semantics as barriers in redundant regions.  I hope 
> this helps a bit.
>
> One other point, semantically "may not" means you are not allowed to 
> do something.  Whereas "can not" means it is not possible to do.  As 
> far as barriers inside of work sharing constructs are concerned the 
> spec says you "may not" place them there because the program will 
> become non-compliant.  However, to say "can not" would require the a 
> compiler to flag the barrier inside of a work sharing construct as an 
> error.  There is a very fine line being drawn here, but it is an 
> important line.  It is actually very possible to write "safe" programs 
> which have barriers inside of work sharing constructs, however, it is 
> dangerous enough that the casual programmer should not attempt it.
>
> BTW, if you look at page 154 of the 2.5 spec it explicitly shows that 
> it is incorrect to place a barrier inside of an omp do construct.
> A modified version of A.20.4f follows.
> !$omp parallel default(shared)
> !$omp do
>    do i = 1,n
>       call work(i,1)
> ! the following barrier shows incorrect nesting of a barrier in a loop 
> region.
> !$omp barrier
>       call work(i,2)
>    end do
> ! the following barrier shows correct nesting of a barrier in a 
> parallel region.
> !$omp barrier
> !$omp end parallel
>
> Does this help?
>
> james