Subj : Re: YALFAm (Yet Another Lock Free Approach, maybe)
To   : comp.programming.threads
From : Chris Thomasson
Date : Sat May 21 2005 05:43 am


>>>Even with the _InterlockedCompareExchange() intrinsic function on 
>>>Windows?
>>
>> Well, I am "not totally sure" of Microsoft's specific guarantees wrt 
>> implementing sensitive multi-threaded algorithms. It might be safe...
>>
>> Yet again, it might not be so safe after all...
>
> Gee, Chris. I have this odd feeling of deja vu. Haven't we, uh, been here 
> before? ;-)

I don't understand why Microsoft can't just write some simple memory 
visibility guarantees. Something like this would be a start:



Lets take the MS CAS Acquire/Release API...


InterlockedCompareExchangeAcquire
------------------------------------

LPLONG dest,
LONG xchg,
LONG cmp


Function Operation
-----------
This function atomically compares (*dest) with (cmp), and exchanges (*dest) 
with (xchg) if they are equal. No update operation is performed on the 
(*dest) if they were not equal. The function always returns the initial 
value of (*dest).


Operation Memory Visibility
-----------
This function guarantees that the return value is loaded or any updates to 
(*dest) are fully applied and made visible to all CPU's before any 
subsequent loads/stores are applied or made visible to any CPU. All 
Microsoft compilers are fully compliant with the guaranteed behavior of this 
function. They will also not optimize anything around calls to this function 
that might break the stated guarantees.







InterlockedCompareExchangeRelease
------------------------------------

LPLONG dest,
LONG xchg,
LONG cmp


Function Operation
-----------
This function atomically compares (*dest) with (cmp), and exchanges (*dest) 
with (xchg) if they are equal. No update operation is performed on the 
(*dest) if they were not equal. The function always returns the initial 
value of (*dest).


Operation Memory Visibility
-----------
This function guarantees that any preceding loads/stores are fully applied 
and made visible to all CPU's before
return value is loaded or any updates to (*dest) are applied or made visible 
to any CPU. All Microsoft compilers are fully compliant with the guaranteed 
behavior of this function. They will also not optimize anything around calls 
to this function that might break the stated guarantees.





Humm, I wonder if that would be good enough explanation of guaranteed 
behavior wrt memory visibility/compiler-safety for acquire/release 
semantics...


;)

.