>>>>> "kai-gcc" == kai-gcc <[EMAIL PROTECTED]> writes:
kai-gcc> A. There's something similar in the C standard: see
kai-gcc> sig_atomic_t. It might be possible to steal some wording
kai-gcc> from there.
kai-gcc> B. This guarantee - at least as I describe it below - cannot
kai-gcc> work for every target. For example, it won't work on a
kai-gcc> typical 8 bit target. That needs to be kept in mind when
kai-gcc> describing it.
kai-gcc> Now, the guarantee as I understand it:
kai-gcc> First, you need the somewhat nebulous concept of a
kai-gcc> "word". On a machine where this guarantee holds, a pointer
kai-gcc> fits in a word, and so does an int.
kai-gcc> Now, the guarantee says that every change to a word will be
kai-gcc> atomic, in the sense described for sig_atomic_t except it
kai-gcc> also works with threads and in the presence of SMP. ...
kai-gcc> Maybe targets that have that guarantee should #define
kai-gcc> something.
I don't much like the notion of a "guarantee" about the semantics of a
supposedly portable language, where that guarantee is
target-dependent.
So are you saying you want this property for plain ordinary C language
references to plain ordinary data types? And the guarantee is
stronger than what C offers for sig_atomic_t?
It seems to me that sig_atomic_t exists because even the weak
guarantee it provides acts as a constraint on the implementation, so
you don't want that overhead for every variable, only for those where
you explicitly call for it by the use of that special type.
Given that, it clearly isn't a good idea to propose a stronger
guarantee for plain old int (or similar) types. Instead, you could
tie it to a new type ("smp_atomic_t"?) and/or new functions
("smp_atomic_load"?) That also serves the useful purpose of
explicitly calling out the places in the source where atomicity
assumptions are made.
paul
