overly strict semantics

Posted Jan 10, 2026 16:55 UTC (Sat) by joib (subscriber, #8541)
In reply to: overly strict semantics by wahern
Parent article: READ_ONCE(), WRITE_ONCE(), but not for Rust

> Also, C11 atomics is not the origin point for atomic intrinsics[1] or a meaningful memory model in either GCC or Linux. It's not the final or even 100% comprehensive model, either. I think the push for a more formal memory model in C, C++, and the compilers gives a false impression such a thing was completely non-existent beforehand and that things are satisfactory today.

I wonder, if the C++/C11 memory models and atomics were to be developed today, how different would they look, considering the amount of knowledge the world has gained since then and now?

Certainly there were parts of the C/C++11 models that were, ahem, less than successful, like the consume memory ordering, but otherwise, would there be a place for doing it substantially better and different in general?

to post comments

overly strict semantics

Posted Jan 11, 2026 20:33 UTC (Sun) by pbonzini (subscriber, #60935) [Link] (1 responses)

One change I would remove is seq_cst stores and memory operations; and in their place I would rather have operations that behave as if they were enclosed by seq_cst fences on both sides, like for example Linux's atomic_add_return. The difference is that a RMW seq_cst operation can be reordered after a subsequent relaxed load, but that's not the case for LKMM and atomic_add_return. So this would actually make semantics *stricter*, not looser.

I don't have high hopes that this would be accepted now, but maybe it would be since "almost nobody will need anything but sequential consistent variables" has been shown wrong.

The other thing that still hasn't been fully formalized is out-of-thin-air values. Everybody agrees that they won't happen but strictly speaking they aren't prohibited, or weren't last time I checked.

overly strict semantics

Posted Jan 12, 2026 6:06 UTC (Mon) by riking (subscriber, #95706) [Link]

The special snowflake global ordering of only seqcst operations (but not seqcst fences) has got to go for sure, and I agree that "operations fused with seqcst fences" would be better.

overly strict semantics

Posted Jan 15, 2026 0:18 UTC (Thu) by milesrout (subscriber, #126894) [Link] (1 responses)

The worst part of the design is _Atomic/std::atomic. Atomic operations are atomic *operations, the operations are atomic. There is nothing inherently atomic or non-atomic about the operands themselves. The operator overloading is also a plain bad idea.

overly strict semantics

Posted Jan 15, 2026 15:40 UTC (Thu) by bertschingert (subscriber, #160729) [Link]

The GCC atomic intrinsics seem to get this right. I'm not sure if there's a portable way to do atomic operations on regular int types, though.

OTOH, what I like about the Rust (and C/C++11?) atomics is that the type system prevents accidentally introducing data races because you can't do a non-atomic load/store to an atomic type -- at least without unsafe code. Given that the article mentions there are cases in C where READ_ONCE() and WRITE_ONCE() should have been used, but weren't, this seems to be a real risk.