[Omp] Still on the barrier (fwd)
Haoqiang H. Jin
hjin at nas.nasa.gov
Mon Mar 12 09:13:21 PDT 2007
It seems that you have not clearly described what you
intended to measure in your experiments. If you barely
want to understand how much time each thread spends
in a barrier (region), then here is a sketch of
such a code:
!$omp parallel default(shared) private(i,j,k,TID)
TID = OMP_GET_THREAD_NUM()
PRINT *, 'thread = ', TID
print *, "March 9"
CALL MAGIC_BRK_SIM_START()
!$omp do
do k = 1, d3
do j = 1, d2
do i = 1, d1
u1(i,j,k) = u0(i,j,k)*ex(t*indexmap(i,j,k))
end do
end do
end do
!$omp end do nowait
print *, "Before barrier"
CALL MAGIC_BRK_SIM_MIDDLE()
!$OMP BARRIER
CALL MAGIC_BRK_SIM_STOP()
print *, "After barrier"
!$omp end parallel
-Henry Jin
**************************************************************
Any opinion expressed is my own and not that of NASA.
On Mon, 12 Mar 2007, James Beyer wrote:
> 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
> _______________________________________________
> Omp mailing list
> Omp at openmp.org
> http://openmp.org/mailman/listinfo/omp
>
More information about the Omp
mailing list