Re: Difference between atomic operations and memory barriers

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

Leonidas . wrote:
> On Tue, Oct 27, 2009 at 3:21 AM, Michael Schnell <mschnell@lumino.de> wrote:
>> Leonidas . wrote:
>>>
>>> any_t *ptr = something;
>>>
>>> is always atomic even on SMPs without using locks, barriers then my
>>> doubt is cleared. Thanks.
>>
>> I assume that this only holds if the pointer (not the thing it points
>> to) is denoted as volatile.

  - Atomic access (either old or new value is visible to CPUs or
    devices, but never any intermediary, half-baked value),
  - memory barrier (enforced order of accesses),
  - volatile qualifier (disabled compiler optimization of accesses)

are three different concepts.

We rely on atomic pointer load and store all over the kernel, yet never
qualify them as "volatile".  (A look into the C language spec might
bring clarity here.  I don't have the spec at hand alas.)

> I dont think so,  volatile would only ensure no caching, so some cpus
> might see the cached pointer (this is where you would want to use
> barriers), but pointer assignment would still be atomic.

What "volatile" ensures or not ensures is not that well defined in the C
language specification as far as I recall prior discussion.  Its precise
effects are compiler dependent.  You are right in so far as volatile
(given or missing) does not change whether an access is guaranteed
atomic or not.  Since it affects compiler optimizations, I think it
could possibly affect atomicity of accesses which were never guaranteed
to be atomic.  But this should not be interesting to 99.99% of all
kernel coders because they better use guaranteed atomic accesses when
they really need them.  (E.g. <linux/atomic.h> or pointer load/ store.)
-- 
Stefan Richter
-=====-==--= =-=- ==-==
http://arcgraph.de/sr/