This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: atomic accesses

>>>>> "kai-gcc" == kai-gcc  <> 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

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]