Re: atomic accesses

[Paul Koning <Paul_Koning at dell dot com>]

>>>>> "Segher" == Segher Boessenkool <segher@kernel.crashing.org> writes:

 >> As I said before, I think any words of this form SHOULD NOT be
 >> added.  All it does is add words to the documentation that provide
 >> NO guarantee of anything -- but in a way that will confuse those
 >> who don't read it carefully enough into thinking that they DID get
 >> some sort of guarantee.

 Segher> The idea is to _do_ provide that guarantee.  If the GCC code
 Segher> does not agree with the GCC documentation, the code has a bug
 Segher> ;-)

 >> In other words, a statement like that has clear negative value.

 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.

First of all, the text you supplied does not create any guarantee at
all.  It says that "whenever possible" GCC will do x.  Translation:
for any given bit of source, target, switches, etc., that means GCC
may do x in that case -- and it also means it may NOT do x in that
case.  Either outcome is legal by the text you proposed.  There is no
bug in GCC, whether it does x or (not x).

So you're not adding a guarantee.  But even though it isn't a
guarantee, it may cause some people to think it is one.  In fact, I'm
tempted to say it's doing that to you.

Now, suppose we take out "whenever possible" and replace it by
"always".  Then it IS a guarantee, and if GCC generates multiple
instructions, it's a GCC bug.  (If we propose to follow this path, do
we have any idea how many instances of that bug exist right now in the
current code generators?)

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.

So, even with the hard requirement for single instruction load/store,
it isn't clear what conclusion a programmer is supposed to draw from
the statement under consideration.

The discussion is about atomicity.  Talking about single instructions
is seriously misleading, because there is only a weak connection
between the two.  It DOES NOT matter to a programmer whether a C
assignment generates one instruction or twenty; what matters are the
semantics guaranteed for that statement.

If we want to have atomicity properties of plain language C
constructs, let's have a statement of exactly what atomicity
properties are to be guaranteed. NOT in terms of generated code, but
in terms of abstract semantics.  It may well be that anythe most
desirable atomicity semantics are too expensive -- you'd end up with
constraints similar to "volatile", or even more so.  But suppose we
could have a particular guarantee.  Then we can see if what "people"
are relying on is in fact addressed by that guarantee, or if they were
expecting a stronger guarantee that they are simply NOT going to get
from GCC (not unless they invoke specific atomic_foo builtins).  If
the former, then GCC has cured a bug in the original application
(perhaps at the expense of work in GCC); if the latter, then the
application bug is still there.

      paul