Re: Memory ordering

On 12/17/2024 4:33 AM, jseigh wrote:

On 12/16/24 16:48, Chris M. Thomasson wrote:

On 12/5/2024 5:00 AM, jseigh wrote:

 

>
Maybe.  For thread local non-shared data if the compiler can make that
determination but I don't know if the actual specs say that.

>
It would be strange to me if the compiler executed a weaker barrier than what I said needed to be there. If I say I need a #LoadStore | #StoreStore here, then the compiler better put that barrier in there. Humm...

 C++ concurrency was designed by a committee.  They try to fit things
into their world view even if reality is a bit more nuanced or complex
than that world view.

Indeed.

C++ doesn't use #LoadStore, etc... memory ordering terminology.  They
use acquire, release, cst, relaxed, ...  While in some cases it's
straightforward as to what that means, in others it's less obvious.
Non-obvious isn't exactly what you want when writing multi-threaded
code.  There's enough subtlety as it is.

Agreed. Humm... The CAS is interesting to me.
atomic_compare_exchange_weak
atomic_compare_exchange_strong
The weak one can fail spuriously... Akin to LL/SC in a sense?
atomic_compare_exchange_weak_explicit
atomic_compare_exchange_strong_explicit
A membar for the success path and one for the failure path. Oh that's fun. Sometimes I think its better to use relaxed for all of the atomics and use explicit barriers ala atomic_thread_fence for the order. Well, that is more in line with the SPARC way of doing things... ;^)