From: Dorian Krause (dorian.krause_at_usi.ch)
Date: Thu Feb 11 2010 - 16:54:19 PST
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 >> >> > >