Re: Difference between atomic operations and memory barriers

[Stefan Richter <stefanr@s5r6.in-berlin.de>]

Leonidas . wrote:
> On Mon, Oct 26, 2009 at 11:49 PM, Noah Watkins <noah@noahdesu.com> wrote:
>>> Trying to understand difference between atomic ops and memory barriers.

Atomic accesses and barriers are different concepts.

The former means that there won't be intermediary values visible (to
another CPU or to a DMA capable device) at any time; there will only be
either the old value or the new value, but nothing half-done.

The latter means that an order between two (or more) separate accesses
is enforced.

You cannot use barriers to make intrinsically non-atomic accesses look
atomically; you need a lock for such a purpose.  (Or RCU.)

>>> I was thinking all atomic operations must be using barrier internally, but I read
>>> somewhere that only some of them use barriers. Sorry for being vague here.
>>> 
>>> Operations before call to smp_mb() will not be re-ordered and all cpus will see
>>> consistent value after the variable is updated.
>>> 
>>> E.g.
>>> void * ptr = (void *) str;
>>> smb_mb();
>>> 
>>> Will this not atomically update ptr? Ptr will be seen by all cpu's in same state
>>> after it has been assigned str, right?
>> 
>> There is a bit of info in:
>>    Documentation/atomic_ops.txt
>>
>> -noah
>>
>>
> 
> 
> Thanks for the pointer, there are no atomic operations for pointers, right?
> I guess barrier is what we need in that case.

There are more atomic accesses than those which deal with atomic_t.  For
example,
	any_t *ptr = something;
is definitely atomic, and we rely on this atomicity in the kernel at
many places.

I guess these things can be found somewhere in the C language specification.
-- 
Stefan Richter
-=====-==--= =-=- ==-=-
http://arcgraph.de/sr/