From: Steve Reinhardt (spr_at_sgi_dot_com)
Date: Sun Nov 06 2005 - 14:19:01 PST
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
> >
> >