From: Marc L. Smith (mlsmith_at_colby_dot_edu)
Date: Sun Nov 06 2005 - 19:37:38 PST
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) {
upc_lock(mutex)
printf("%d: %s\n", tick, s);
tick++;
upc_unlock(mutex);
}
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)
upc_barrier;
if (MYTHREAD == 0) {
printf("all threads finished\n");
}
The order of printf's may look strange, but they should all appear.
Good luck.
-Marc
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
>> >
>> >
>