Subj : Re: Memory visibility and MS Interlocked instructions
To   : comp.programming.threads
From : Joe Seigh
Date : Sat Aug 27 2005 12:25 pm

Joe Seigh wrote:
> * The one exception I'm aware of (because I use it myself) is atomic
> load depends and we can get away with that because so much of lock-free
> depends on pointer swizzling.
> 

Speaking of that, what do most people think are its semantics?  A qualified
acquire (#LoadLoad+#LoadStore) or just a qualified #LoadLoad?

I believe Linux uses the former.  The only platform that requires an explicit
memory barrier, Alpha, has no #LoadLoad equivalent, just a full membar and
a #StoreStore membar.  And current dependend loads on the other platforms have
acquire semantics AFAIK.

I'm thinking of making the atomic_load_depends in my set of atomics just
provide #LoadLoad semantics.  Because I strongly suspect that Intel and/or
AMD will break the dependent load hack down the road.  If you have acquire
semantics, then you will be forced to use MFENCE which will affect
performance more than just using LFENCE for #LoadLoad semantics.

If you go the #LoadLoad route, then writing to shared objects accessed by
dependent load will require exlicit synchronization to ensure full acquire
semantics, something that is likely being used anyway.

I'm trying to avoid being blindsided by Intel/AMD who seem to have almost
no awareness of what's going on in synchronization.


-- 
Joe Seigh

When you get lemons, you make lemonade.
When you get hardware, you make software.

.