Re: bug with global UPC variables

From: Paul H. Hargrove (PHHargrove_at_lbl_dot_gov)
Date: Thu Feb 28 2008 - 15:01:48 PST

  • Next message: James Noble: "memory leaks with upc_all_alloc"
      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
    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.
    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

  • Next message: James Noble: "memory leaks with upc_all_alloc"