Re: P.S. Re: UPC program acting like no synchronization

From: Marc L. Smith (mlsmith_at_colby_dot_edu)
Date: Sun Nov 06 2005 - 19:37:38 PST

  • Next message: Dan Bonachea: "Re: P.S. Re: UPC program acting like no synchronization"
    Hi Steve,
    I haven't used bupc_trace_printf, and don't really know what its  
    purpose in life is, but it sounds like it *might* be helpful.  I'll  
    wait for one of the UPC folks to comment on it.  :-)
    As for the printf ordering, I use it to my advantage in the classroom  
    to illustrate the phenomenon and challenges of nondeterminism.  So in  
    one sense, I *like* that you can't count on the order of print  
    statements...  :-)  But I also see the potential for frustration.  
    Time stamps may be a help, but keep in mind using some other routine  
    -- depending on what you do -- could change the behavior of the  
    program at runtime.  For example, you could implement
    upc_lock_t * mutex;
    // initialize mutex -- all threads get same lock pointer...
        mutex = upc_all_lock_alloc();
    // for all threads to access and increment with each printf
    shared int tick = 0;
    void my_printf(char *s) {
         printf("%d: %s\n", tick, s);
    Then call my_printf() whenever you want to print.  This will give you  
    a total ordering on your printf's (no matter what order they print),  
    but the synchronization required to achieve this ordering will effect  
    the runtime behavior of your program.
    So, maybe bupc_trace_printf is the answer?  Let's see what they  
    say...  :-)  As for your initialization code, it all looks kosher to  
    me, no matter whether you have thread 0 or 1 do the initialization.   
    Are you sure the nondeterministic printf's aren't misleading you?
    You could put a footer in your main() like this, just after your  
    parallel work, which should permit all prior thread's printf's to  
    flush before terminating:
    > ... parallel work (including some printf()s)
    if (MYTHREAD == 0) {
       printf("all threads finished\n");
    The order of printf's may look strange, but they should all appear.
    Good luck.
    On Nov 6, 2005, at 5:30 PM, Steve Reinhardt wrote:
    > P.S.  Ah, now I see bupc_trace_printf.  Is that what people  
    > typically use?
    > Hi Marc,
    > At 01:46 PM 11/6/2005, Marc L. Smith wrote:
    >> Is this barrier question unique to such high-end platforms?  I've
    >> used the upc_barrier calls on my beowulf cluster without any problems
    >> -- at least, I don't think I'm having any problems.  :-)  One thought
    >> is you can't rely on the order print statements appear, as the
    >> buffering can fool you into thinking barriers are being ignored.  To
    >> test this theory, remove the barrier statements and see if the
    >> behavior is the same.
    > I'm trying to allow some data structures to get initialized before  
    > all the other threads join the fray.  Basically it's
    > if (MYTHREAD == 0) {
    >         ...initialization stuff... (including some printf()s)
    > }
    > upc_barrier;
    > ... parallel work (including some printf()s)
    > Running on 2P, it runs approximately as I'd want it to, except that  
    > thread 1 appears not to participate.  If I toggle the  
    > initialization work to be done on thread 1 instead of thread 0, it  
    > appears that thread 0 goes past the barrier prematurely.
    > I see what you mean with the "buffering" comment, as
    > upc_barrier;
    > if (MYTHREAD == 0) printf ("hit point 0\n");
    > upc_barrier;
    > if (MYTHREAD == 1) printf ("hit point 1\n");
    > upc_barrier;
    > if (MYTHREAD == 0) printf ("hit point 2\n");
    > upc_barrier;
    > gives the output
    > hit point 0
    > hit point 2
    > hit point 1
    > How do people overcome this to debug with printf?  Add time  
    > stamps?  Use some other routine?
    > Thanks.                                 Steve
    >> -Marc
    >> On Nov 6, 2005, at 2:34 PM, Steve Reinhardt wrote:
    >> > Hi,
    >> >     I'm just getting up to speed with running UPC, on an SGI Altix
    >> > system.
    >> >
    >> >     The code compiles and loads cleanly and runs without error (via
    >> > upcrun ...), but even though I have a couple upc_barrier calls to
    >> > synchronize things, it appears to be ignoring them.  I seem to
    >> > remember that there might be some issue about getting bupc_init
    >> > called, and without it I might get these symptoms.  Is there any
    >> > documentation somewhere to walk me through this?  Searching around
    >> > hasn't unearthed anything.
    >> >
    >> >     Any suggestions?  Thanks.        Steve
    >> >
    >> >

  • Next message: Dan Bonachea: "Re: P.S. Re: UPC program acting like no synchronization"