Hacker News Reader

Comment by dragontamer | Hacker News Reader

> The basic problem is that for any physical core, there is no guarantee that any writes will ever be seen by any other core (unless the necessary extra magic is done to make this so).

They're using atomic read/writes with sequential-consistency.

This means that the compiler will automatically put memory-barriers in the appropriate locations to guarantee sequential-consistency, but probably at a significant performance cost.

The implementation is likely correct, but its the slowest performance available (seq-cst is the simplest / most braindead atomic operation, but slowest because you probably don't need all those memory barriers).

I'd expect that Acq-release style barriers is possible for this use case, which would be faster on x86, POWER, and ARM systems.

View on HN

> They're using atomic read/writes with sequential-consistency.

In the C11 code? I'm not up to speed with that version of the spec, but unless there is behaviour invoked by the use of _Atomic, the code looks to me to be performing normal, non-atomic read/writes.

Another reply says there are full barriers being automatically used, but that doesn't address the problem I've described.

> but unless there is behaviour invoked by the use of _Atomic

That is the behavior invoked by "atomic".

The general gist is that "manual" read/write barriers were too difficult to think about and led to bugs. Instead of having the programmer put the read/write barriers in the correct locations, modern compilers put a type-specification on variables... and then its the compiler's job to put the barriers in the correct location.

This turned out to be necessary, because the compiler's optimizer kept rearranging code (!!!) around memory barriers anyway. So the "compiler" needs to participate in any of the barriers, especially at higher levels of optimization (-O3 rearranges a lot of code). If the compiler needs to participate, you might as well have the compiler handle the placement of those barriers.

"Atomic" variables by default will be sequentially-consistent (ie: the _maximum_ use of memory barriers for _maximum_ levels of consistency).

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.

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.

> 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.

> 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.

Reply on news.ycombinator.com