Re: Atomic set for double

From: Paul H. Hargrove (PHHargrove_at_lbl_dot_gov)
Date: Thu Feb 11 2010 - 20:00:36 PST

  • Next message: Dorian Krause: "Re: Atomic set for double"
    Nikita Andreev wrote:
    > Dorian,
    >
    >> a) There is no user control over the "affinity" of a lock, right? It
    >> seems to me that e.g. in your Berkeley implementation, all locks are
    >> managed on thread 0. It appears to me that "localized locks" with
    >> affinity to some thread would be nice to have in the standard ...
    >
    > Paul, correct if I'm wrong but in UPC you can use 
    > upc_global_lock_alloc. It returns a pointer to the lock object in the 
    > calling thread. The pointer itself can be declared in the thread's 
    > private space.
    >
    > Nikita
    >
    
    Dorian,
    
    Nikita is right, at least with respect to the Berkeley implementation: 
    upc_global_lock_alloc() will return a lock "local" to the caller.
    
    The UPC spec is, as far as I can tell, silent on where locks live in 
    memory.  They are represented by a pointer-to-shared, but it is stated 
    explicitly that upc phaseof(), upc threadof(), and upc addrfield() are 
    NOT defined.  This allows the freedom for an implementation to implement 
    them totally outside the normal UPC shared heap if desired.  In fact, I 
    believe it would be legal to have a distinct "lock server" process or 
    pthread that was not a UPC thread.
    
    There are two functions for allocating a UPC lock (static definitions 
    are prohibited):
      upc_all_lock_alloc() is called collectively and all UPC threads 
    receive the same pointer
      upc_global_lock_alloc() is called by a single thread.
    
    In Berkeley UPC we do allocate the locks from the UPC shared heap:
       In the case of the collective upc_all_lock_alloc() all such 
    allocations ARE from thread 0.
       In the case of the non-collective upc_global_lock_alloc() the 
    allocation is local to the calling thread.
    
    However, an implementation is allowed, as far as I can tell, to allocate 
    locks anywhere they wish.  In fact they are probably free to have them 
    migrate dynamically if the implementer was inclined.
    
    I am inclined to agree that user-control over lock locality would be 
    good to have in the spec.
    
    -Paul
    
    -- 
    Paul H. Hargrove                          PHHargrove_at_lbl_dot_gov
    Future Technologies Group                 Tel: +1-510-495-2352
    HPC Research Department                   Fax: +1-510-486-6900
    Lawrence Berkeley National Laboratory     
    

  • Next message: Dorian Krause: "Re: Atomic set for double"