Re: Atomic set for double

From: Dorian Krause (dorian.krause_at_usi.ch)
Date: Thu Feb 11 2010 - 16:54:19 PST

  • Next message: Nikita Andreev: "Re: Atomic set for double"
    Hi Paul,
    
    thanks for your answer (and also the other times you helped me out via 
    bugzilla :) ) ...
    
    Concerning locks it appears to me that they are kind of inefficient in 
    UPC (but, I would be happy to be wrong on this point). There are mainly 
    two points:
    
    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 ...
    
    b) In the Berkeley implementation I noticed that upc_lock_attempt and 
    upc_lock functions only make progress when THREAD 0 is not stuck in 
    computation (in the attached picture (hope you can open it ...), yellow 
    bars are upc_lock_attempt and brown bars are upc_lock; both seem to be 
    stuck unless THREAD 0 is doing communication (green bars are 
    upc_memget)). Is this correct or maybe an artifact of the tracing?
    I know that many MPI implementation have the same behavior for 
    non-blocking and also one-sided communication (i.e. they make only 
    progress if targets make calls to the runtime), but I wouldn't have 
    expected this for UPC/Gasnet.
    
    Thanks again for your help!
    Dorian
    
    
    On 2/11/10 1:44 AM, Paul H. Hargrove wrote:
    > Dorian,
    >
    > I am 98% sure that you are correct that UPC does not guarantee atomicity
    > for programs with data races.
    > You are also correct that the bupc_atomic_* extensions only provide for
    > atomicity among accesses made via bupc_atomic_*.
    >
    > I am not aware of any portable manner in which one can obtain atomicity
    > in UPC except via locks or barriers.
    >
    > -Paul
    >
    > Dorian Krause wrote:
    >    
    >> Dear list,
    >>
    >> if I understand it correctly, the UPC standard does not provided any
    >> atomicity guarantees for load/store operations to the shared memory.
    >> Is there any way for implementing atomic set function for double values?
    >>
    >> BUPC provides the bupc_atomic* extensions which could be used for
    >> storing a 64 bit double value atomically. However, as I understand it
    >> these functions do not work if another thread accesses the memory
    >> region with upc_memget() instead of bupc_atomicX_read(), right?
    >>
    >> Thanks,
    >> Dorian
    >>
    >>      
    >
    >    
    
    
    


  • Next message: Nikita Andreev: "Re: Atomic set for double"