[Omp] Still on the barrier (fwd)

[Shengyan Hong]

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