atomic accesses

[kai-gcc@khms.westfalen.de]

On Tue, Mar 04, 2008 at 04:41:16PM -0500, Paul Koning wrote:
> >>>>> "Segher" == Segher Boessenkool <segher@kernel.crashing.org> writes:
>  Segher> I disagree.  People are relying on this undocumented GCC
>  Segher> behaviour already, and when things break, chaos ensues.  If
>  Segher> we change this to be documented behaviour, at least it is
>  Segher> clear where the problem lies (namely, with the compiler), and
>  Segher> things can be fixed easily.
> 
>  Segher> The two big questions are:
> 
>  Segher> 1) Do we *want* to guarantee any behaviour in this area?
> 
>  Segher> 2) Exactly *what* behaviour?
> 
> Yes, that's the question.

> But what does such a statement guarantee?  Atomic access?
> 
> What exactly does "atomic access" mean?  It might mean, as one of the
> earlier notes said, that in a single writer multiple reader setting
> you will only ever see the "before" or the "after" states but not the
> one in between.
> 
> It's probably true for most architectures (perhaps even for all that
> GCC supports) that this limited interpretation of "atomic" is
> satisfied when the load or store is a single instruction, aligned, the
> right size, etc.
> 
> Another possible interpretation of "atomic" is "if there are multiple
> writers, one write won't interfere with the other". For example, if
> one writer updates X, and another updates Y, two aligned variables
> adjacent in memory, the final outcome has the new X and the new Y.
> 
> That interpretation in general is NOT satisfied simply by using a
> single instruction for store.  Maybe it is on x86 -- but not
> necessarily so on RISC machines.

Well, as I've both relied on that guarantee as well as recently
explained it to a colleague, maybe I should try to explain it.

First, though, two things:

A. There's something similar in the C standard: see sig_atomic_t. It
might be possible to steal some wording from there.

B. This guarantee - at least as I describe it below - cannot work for
every target. For example, it won't work on a typical 8 bit target. That
needs to be kept in mind when describing it.

Now, the guarantee as I understand it:

First, you need the somewhat nebulous concept of a "word". On a machine
where this guarantee holds, a pointer fits in a word, and so does an
int.

Now, the guarantee says that every change to a word will be atomic, in
the sense described for sig_atomic_t except it also works with threads
and in the presence of SMP. Anything that does not fit in a word needs a
lock if there is more than one thread. (Obviously, a sig_atomic_t ought
to be a word on such a machine.)

There is also no guarantee for anything that is only a part of a word
(bitfield, char, ...) unless it is unpacked enough to not share its word
(such as a typical standalone char variable outside of -Os).

It might be necessary to add some more conditions to make this work on
targets I am not familiar with. But it is clear that it cannot work on a
machine where a pointer does not fit in a sig_atomic_t sized thing (such
as where sig_atomic_t is only 8 bit, and storing a pointer needs several
instructions that might be interrupted by a thread switch).

Maybe targets that have that guarantee should #define something.