From: Dorian Krause (dorian.krause_at_usi.ch)
Date: Fri Feb 12 2010 - 03:09:22 PST
> 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. > Nikita, Paul, thanks a lot. Changing calls from upc_all_lock_alloc() to upc_global_lock_alloc() indeed makes a difference (not in run-time, though ...). Still I see that upc_lock_attempt and upc_lock require active participation by the thread "hosting" a lock. To show what I mean, I attached a test program which lets a master thread sleep and a slave tries to acquire a lock. On my system (Opteron, ibv) I see the output: pvfs2-compute-2-13% upcrun -n 2 ./test_upc UPCR: UPC thread 0 of 2 on pvfs2-compute-2-13.local (process 0 of 2, pid=8829) UPCR: UPC thread 1 of 2 on pvfs2-compute-2-13.local (process 1 of 2, pid=8830) [0]: Done sleeping. [1]: Got the lock; took me 7.462001e-02 [0]: Done sleeping. [1]: Got the lock; took me 1.491880e-01 I don't quiet understand these results. Can't the lock simply be implemented using e.g. bupc_atomic* functions without this "two-sided" behavior? Dorian