Talk:c/atomic/atomic fetch add

1. include <threads.h> does not work in the examples -- threads.h no such file or directory :(

2A02:6B8:0:3A05:5C35:CE68:FFFD:D3B9 02:16, 22 April 2021 (PDT)

the online compiler in use here doesn't support that part of C11. But you can run the example on godbolt for example: https://godbolt.org/z/rTPsWGbGn --Cubbi (talk) 20:11, 26 April 2021 (PDT)

Memory order for atomic_fetch_add_explicit in example

How I read the definition of memory_order https://en.cppreference.com/w/c/atomic/memory_order a read-modify-write (like fetch_add here) would require to specifiy a memory_order that gurantees that writes happening in the last call of the command are visible in the next call of the command. memory_order_relaxed does not gurantee and ordering among threads, so shouldn't it be memory_order_acq_rel here?

(Destranix (talk) 07:53, 9 November 2022 (PST))

no. acq_rel and other orders are about *other* (typically non-atomic) memory locations. Not the atomic involved in the operation. --Cubbi (talk) 08:25, 9 November 2022 (PST)

Do you have a source for this statement? Cause reading the description of memory_order_relaxed it sounds like (it's explicitly stated that) no synchronisation happens, only atomicy and order within the thread is guranteed.

c/atomic/memory_order#Relaxed_ordering does not say "order within the thread", it says "modification order consistency", which is the property of all atomic variables. Note also, same relaxed ordering section says "Typical use for relaxed memory ordering is incrementing counters" --11:13, 9 November 2022 (PST)

Ah okay, that explains a lot. Thank you.

Maybe it should be somehow clarified which atomic operations gurantee what ordering. On the sites I found the gurantees are defined using a "happens before", but "happens before" is only defined in the cpp version and does not seem to handle cases between atomics with no memory-order (but some terms don't seem to be defined or linked like "synchronizes-with" and also "consume operation" might maybe me intended to also mean certain atomic operations regardless of memory_order specified in the command).

yes, there's an unfinished todo marker in c/atomic/memory_order to fill in the formal description, which is pretty much the same as C++'s cpp/atomic/memory_order, C committee copied it. Atomic operations on their own do not order non-atomic memory accesses, it's the release/acquire/consume/seqcst operations that do so. You can make an atomic op to *also* be a release/acquire/consume/etc op by specifying non-relaxed memory_order parameter, because many algorithms need both at the same time, but you can also do it without an atomic. --Cubbi (talk) 21:36, 10 November 2022 (PST)

Yeah, I understood that. I just find it confusing that https://en.cppreference.com/w/c/language/atomic says something like this:

There are four coherences that are guaranteed for all atomic operations:

* write-write coherence: If an operation A that modifies an atomic object M happens-before an operation B that modifies M, then A appears earlier than B in the modification order of M.

Using "happens-before", but "happens-before" is then defined using memory-order although theese gurantees also apply when no memory-order (memory_order_relaxed) is used.

So maybe one should add a sentence to the description saying something like:

"For two operations that access an atomic variable one of both always happens-before the other"

Also maybe it should be explicitly noted, that this also means, that all modifications on an atomic that happened-before are visible to all successing modifications in the modification order.

(Destranix (talk) 00:13, 11 November 2022 (PST))

In int a,b; a=1; b=2;, modification of a happens-before modification of b, nothing to do with memory order or atomicity. write/write says given atomic_int a; atomic_store(&a, 1, memory_order_relaxed); atomic_store(&a, 2, memory_order_relaxed); in a's personal timeline ("modification order") 1 will appear and then 2 will appear, compiler isn't permitted to swap them around. And even if the ``happens-before`` is a longer chain of sequencings and synchronizations (which indeed may involve release/acquire operations, some of which indeed may involve atomic ops with explicit memory orders), compiler still must ensure the coherence holds. --Cubbi (talk) 08:14, 11 November 2022 (PST)

I understand that. I'm just saying that it's not that easy to get an understanding of it using the given text on https://en.cppreference.com/w/c/language/atomic if you don't already know what should happen.