Question Details

No question body available.

Tags

c language-lawyer atomic

Answers (2)

Accepted Answer Available
Accepted Answer
March 15, 2026 Score: 5 Rep: 63,114 Quality: Expert Completeness: 80%

§7.17.7.5 p5 was headed "Note", and in all ISO standards, notes aren't normative. So no implementer should ever have been using that paragraph to decide whether compound assignment operations should be atomic.

On the other hand, §6.5.16.2 p3 is normative, and states very clearly that compound assignment operators, applied to atomic types, operate atomically. So that's what implementers should have done.

I think the author of §7.17.7.5 p5 was trying to draw a comparison with compound assignment operators in general, as applied to types that are not necessarily atomic, which they probably thought would be more familiar to readers. Again, not as a way to define the behavior of atomicfetch (because the paragraph is non-normative), but as an aid to understanding. It wasn't very successful, but I expect that implementers would nonetheless have understood in context what was meant, and wouldn't have been confused.

Certainly in the major implementations, the compound assignment operators, when applied to atomic types, have indeed acted as atomic read-modify-write operations, ever since the introduction of atomic types in C11. I think that is very safe to rely on (barring bugs, as always).

All that said, I would still prefer to use the atomic_fetch_ functions whenever possible: they make the atomic operation more explicit, and allow one to specify the memory ordering. Also, it's usually more useful to get the object's old value, rather than the new one.

There are a few odd instances where compound assignment permits an atomic operation for which there's no corresponding atomicfetch function: =, %=,

March 15, 2026 Score: 1 Rep: 192,562 Quality: Medium Completeness: 30%

Because this seems to have been a defect in the standard, is it therefore safe to assume compound assignments on atomic variables are atomic even when using older compilers or compilers in pre-C23 mode?

That reasoning is not sound.

N2389 claims that the inconsistency between C17 sections 6.5.16.2 and 7.17.7.5 should be resolved in favor of of the former (compound assignment operating on an atomic object has atomic read-modify-write semantics with sequential consistency memory ordering). This view seems correct because 7.17.7.5/5 is labeled as a note, and notes in the specification are informative, not normative. Also, inasmuch as the note can be taken as an attempt to discuss behavior described elsewhere, as opposed to specifying anything itself, the actual specification of the behavior in 6.5.16.2 should be taken as authoritative here. The committee evidently agreed, whether for those reasons or others, as C23 removes the inconsistent note.

HOWEVER, that speaks only to how the language spec ought to be interpreted, not to what C implementations actually do. Compilers do have bugs, and bugs in this area could be subtle enough to go unnoticed for some time. It's reasonable to hope that compiler developers understood the spec correctly, including the C11 and C17 versions containing the erroneous note. It's reasonable to trust compiler developers to get these details right as much as you trust them to get other details of atomics right. On the other hand, it's not altogether unreasonable for the erroneous note to undercut your confidence.

If your compiler's reputation and your experience with it is insufficient to inspire trust in you in this area then you should either test your compiler by checking what code it actually produces for a variety of compound assignments to atomic objects, or you should sidestep the question by spelling such compound assignments using the function call option.