On Tue, Mar 04, 2008 at 04:41:16PM -0500, Paul Koning wrote: > >>>>> "Segher" == Segher Boessenkool <[EMAIL PROTECTED]> 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.
