Re:A flexible, lightweight, spin-lock barrier
by MaxGanzII on Tuesday March 15, 2022 @05:55PM
(#30692345)
> 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.
Re:A flexible, lightweight, spin-lock barrier
by dragontamer on Tuesday March 15, 2022 @06:05PM
(#30692477)
> 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.
_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.