Bang Jun-Young wrote:
> On 3/14/07, Johnny Billquist <bqt@softjar.se> wrote:
> 
>> Memory barrier or not, I wouldn't expect the above code to work anyway.
>> The value of the target could very well change between the read and the
>> actual store.
>> So you could actually have a situation where old == cmp, but the store
>> didn't take place, since the value of target changed before the
>> atomic_compare_and_store. Thus, you might think that you did a write,
>> but in reality you didn't.
>> The value of *target can change between the read and the atomic modify.
>>
>> Or am I missing something?
> 
> atomic_compare_and_store() doesn't guarantee that it returns the old
> value of *target you expect, either. If *target was modified within
> atomic_compare_and_store() before the actual atomic instruction was
> executed, the modified value would be returned instead of the expected
> one.

Isn't the whole point of a function called "atomic_compare_and_store" 
that it would be atomic? Otherwise I would say that it was misnamed.
So, it should not be possible for *target to be modified withing the 
atomic_compare_and_store by some other entity, or the function isn't atomic.

And doing tests in a loop outside isn't solving the puzzle. If the 
values can be changed by some other entity in parallell, you'll always 
be in trouble. The only solution is to provide a guaranteed atomic 
operation, or use a mutex to guarantee exclusive access to the data you 
want to manipulate.

	Johnny