Re: Memory ordering

On Tue, 17 Dec 2024 20:41:23 +0000, Chris M. Thomasson wrote:

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.

A committee with no/little HW design experience ...

>

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?

There are architectures in which CAS* is allowed to fail spuriously.
In one case, if the miss buffers overflow while holding a locked
variable, the CAS would fail (preventing an ABA problem possibility).
(*) or any multi-instruction ATOMIC sequence.

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... ;^)

:-)