[dragontamer]

https://en.cppreference.com/w/c/language/atomic

_Atomic types can be read-modified-written atomically (if using a compound-assignment operator), or the postincrement/pre-increment operations.

In these circumstances, the memory-barriers used for those atomic-operations will be of the sequentially-consistent memory model.

------

So yes, that "++*barrier" operation is read-modify-write atomically AND with memory-barriers in sequential-consistency style

-----

I don't believe that "atomics" are enough to solve this problem. At a minimum, I expect acq-consume to be required (not that acq-consume model even works in practice... so acq-release for today's compilers). That's why I'm still talking memory model / fences here.

Not only is an atomic operation required, but so too is the "publishing" of this information needing to happen in the proper order. Fortunately, C11's _Atomic implementation solves both issues.

[MaxGanzII]

> So yes, that "++*barrier" operation is read-modify-write atomically AND with memory-barriers in sequential-consistency style

The quoted material does not describe this assertion.

[dragontamer]

> Built-in increment and decrement operators and compound assignment are read-modify-write atomic operations with total sequentially consistent ordering (as if using memory_order_seq_cst). If less strict synchronization semantics are desired, the standard library functions may be used instead.