4 ms·

You're talking here about memory barriers, but I was asking if atomic writes are in use. Atomic writes have nothing to do with memory barriers. On modern plat

You're talking here about memory barriers, but I was asking if atomic writes are in use. Atomic writes have nothing to do with memory barriers. On modern platforms atomic writes are available without memory barriers of any kind. Memory barriers do not cause events to become visible. Only atomic writes do this; and so the question is not whether barriers are in use due to _Atomic, but whether atomic writes are in use due to the use of _Atomic.

deleted 5y ago
[deleted]
dragontamer 5y ago
https://en.cppreference.com/w/c/language/atomic 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 5y ago
  > 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 5y ago
    > 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.

deleted 5y ago

[deleted]

dragontamer 5y ago

https://en.cppreference.com/w/c/language/atomic 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 5y ago
> 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 5y ago
  > 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.