Re: Memory barriers in atomic operations

FreeMan <basurero@[EMAIL PROTECTED]
> writes:
> On 2008-07-25 00:55:20 +0200, Greg Parker <gparker@[EMAIL PROTECTED]
> said:
>> Your case of one-writer multiple-readers may or may not need a barrier.
>> It depends what the atomic value is for and how the writer and readers
>> expect it to relate to other values.
>
> Thank you. This is the point in which I am interested in. Assuming that
> only one thread modify the atomic variable: Under which conditions a
> problem/different behavior can arise? Can you provide an example where
> memory barriers solve such problem?

Again, it depends how your atomic variable is related to other variables.

Here's another example. One thread adds items to an array, then 
atomically increments the array count. Other threads are continuously 
reading the array. 

Writer:
    Item *newItem = [[Item alloc] init...];
    array[count] = newItem;
    OSAtomicIncrement(&count);

Reader:
    for (i = 0; i < count; i++) {
        [array[i] doSomething];
    }

This will crash without proper barriers. The reader threads may be able 
to see the updated count before they see the updated array value. The 
garbage value read from the array then causes a crash or other incorrect 
behavior. 

Note that OSAtomicIncrementBarrier() is not enough to fix the problem 
on some architectures; they also need a memory barrier on the reader's 
side to guarantee the desired synchronization.


-- 
Greg Parker     gparker@[EMAIL PROTECTED]
     Runtime Wrangler