From: Paul H. Hargrove (PHHargrove_at_lbl_dot_gov)
Date: Sat Jun 06 2009 - 13:57:15 PDT
A barrier is a concept, like the semaphore and condition variable, used
to control execution in parallel programs. I can be implemented in terms
of condition variables.
In the simplest terms a barrier ensure that all threads have reached the
barrier before any of them may execute past it. Depending on the model,
a barrier might be a specific line of source code that all threads must
reach, or it can be a barrier object which different threads might name
from different locations in the source code, or in might be an anonymous
object that may be called from any line of source. The BLCR
implementation of a barrier is a named object. Most versions of a
barrier will "reset" back to their initial state after all threads have
arrived, and they can then be used again. However, BLCR's barriers are
only valid for a single use.
The cr_barrier_enter() implements a barrier such that any thread calling
cr_barrier_enter() is blocked in that call until the required number of
threads have made the same call (the number being determined by the
cr_barrier_init() call and any subsequent atomic_inc(&X->count) calls).
However, we also have a split-phase barrier. In a split-phase barrier we
think of "notify" and "wait" as two distinct steps and allow the thread
to do additional useful work between them. The rule is that a call to
cr_barrier_notify() is non-blocking, and a call to cr_barrier_wait()
will block until the required number of threads have called
cr_barrier_notify() for the same barrier object. Note that each thread
must call notify() before it may legally call wait().
For more information about barriers in more common environments, there
are a few places you may look:
+ documentation for "pthread_barrier_wait" for the pthreads
implementation of barriers
+ documentation for "MPI_Barrier" for the barrier in MPI (the Message
Passing Interface)
+ a book or tutorial on the UPC (Unified Parallel C) language for
another example of a split-phase barrier
-Paul
����� wrote:
> Hello professor:
>
> There is a problem which has been puzzling me all the time when I read
> the code of BLCR, Everytime I met with those part of the code I just
> try to understand it , but still can not understand it very well. Now
> I think it��s time to consult you about the ��Cr_barrier��.
>
> For example: code section in cr_dump_self:
>
> /* Now use vmadump to write out the state for the thread.
> ALL threads call this and serialization is done within */
> ...
> bytes = cr_freeze_threads(proc_req, 0, i_am_leader);
> if (bytes < 0) {
> result = (int)bytes;
> ...
> cr_barrier_notify(&proc_req->vmadump_barrier);
> goto out;
> }
> CR_KTRACE_LOW_LVL("thread finished vmadump");
>
> /* Need a barrier here to ensure all threads write their regs before
> the next
> * write to the file.
> */
> if (cr_barrier_enter(&proc_req->vmadump_barrier)) {
> CR_KTRACE_LOW_LVL("process finished vmadump");
> }
>
> It seemed to use cr_barrier_enter to ensure all threads write their
> regs before the next write to the file. Why can not a thread continue
> to write before all threads write their regs just through invoking
> this function? I know it use semaphore & condition Variables ? Can you
> help me to understand how it works?
>
> I will be very greateful if you can introduce more about ��barrier�� to
> me systematially . Please forgive me if you think it as an excessive
> demand. Thank you.
>
>
>
>
>
> ===============================================
> ��������һ������TOM�������ɣ���������1.5G������ʲô��
> <http://bjcgi.163.net/cgi-bin/newreg.cgi?%0Arf=050602>
> ===============================================
>
--
Paul H. Hargrove PHHargrove_at_lbl_dot_gov
Future Technologies Group Tel: +1-510-495-2352
HPC Research Department Fax: +1-510-486-6900
Lawrence Berkeley National Laboratory