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

Alexander Terekhov wrote:
> Joe Seigh wrote:
> 
>>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?
> 
> 
> Unidirectional ddacq (ddhlb+ddhsb). The problem is that compiler may be
> inclined to turn your data dependency into control condition for which 
> you'd need ccacq (cchlb+cchsb), not ddacq. Note also that while cchsb 
> is implied on on all existing hardware, cchlb is not.
> 

Compiler issues aside.  And its not existing hardware I'm worried about.
A lock-free linked list traversal wins over a locked version because
in part the lock-free list node accesses aren't any more expensive
than the locked ones.  That would change if you had to put in full
membars.  Although the tests I did with hazard pointers w/ and w/o
membars didn't show the former doing all that horribly.  But I think
I'm getting mixed signals here.  Do full memory barriers matter and
if not why is anyone wasting time trying to optimize them?


-- 
Joe Seigh

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

.