From: Paul H. Hargrove (PHHargrove_at_lbl_dot_gov)
Date: Thu Feb 28 2008 - 15:01:48 PST
James, What you have encountered is one of the "dirty little secrets" of our ptherads-based implementation. Without going into all the details, we need to ensure that process-scope variables from system headers (like stdin, for instance) are not accidentally made into thread-scoped variables. To do this we apply a heuristic to #include'd files. Slightly simplified, the heuristic assumes all included files contain C code (and thus declares variables at process scope), UNLESS one of the following is true: 1) Has .upc or .uph suffix 2) Contains a UPC keyword or function (e.g. static, shared, upc_for_all, upc_all_alloc, etc.) 3) Contains "#pragma upc upc_code" 4) Includes other files that meet any of these requirements As a heuristic, this is not a perfect solution and since your example private-2.h file fits none of those criteria, we incorrectly assume "value" should be given process scope. Note that item #3 was implemented precisely to deal with the problem you are experiencing. By using the criteria above, you have at least 2 quick solutions available to you. 1) Rename private-2.h to private-2.uph or 2) Add a line containing "#pragma upc upc_code" to the top of private-2.h Using your test code I've manually verified that applying either (or both) of these resolves the problem you've reported. Please let us know if you have any more problems or questions regarding Berkeley UPC. -Paul James Noble wrote: > Hi, > > I've discovered that a private copy of a global UPC variable is not > made for each thread if the global variable is defined in a separate > UPC source file. I've observed this behavior for both BUPC 2.4 and > 2.6 with the smp and udp conduits with pthreads enabled. > > I've attached some files that demonstrates what I've stated. The > makefile will build two executables. private-1.bin demonstrates that > a global variables are handled correctly if the variable is used in > the file that is was defined. private-2.bin demonstrates that a > global variable defined in a separate file is not handled correctly. > > > > -- > James Noble > > Box F > Division of Applied Mathematics > Brown University > Providence, RI 02912 > > email: noble_at_dam_dot_brown_dot_edu > work: (401) 863-1594 > cell: (401) 261-6048 > > > -- Paul H. Hargrove PHHargrove_at_lbl_dot_gov Future Technologies Group HPC Research Department Tel: +1-510-495-2352 Lawrence Berkeley National Laboratory Fax: +1-510-486-6900