Re: Question about "fd" token

From: Paul H. Hargrove (PHHargrove_at_lbl_dot_gov)
Date: Sat Jun 06 2009 - 13:57:15 PDT

  • Next message: Neal Becker: "Re: More on fedora f11 build failure"
    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     
    

  • Next message: Neal Becker: "Re: More on fedora f11 build failure"