> "acquire" just meant "a load cannot be reordered before this barrier"

I'm pretty sure its "loads / stores cannot be reordered before this barrier". And technically, its "load-acquire", because the load-acquire is what the ordering is relative against. The C++ model does not match assembly-language of various architectures (though ARM64 was designed with C++11's memory model in mind)

Ditto with store-release. "loads/stores cannot be reordered past the store-release".

---------

    // Writing to protectedValue1 must occur after the lock.
    lock(); // load-acquire is part of all locks
    protectedValue1 = foobar();
    localVariable = protectedValue2;
    unlock(); // store-release is part of all unlocks
    // Reading protectedValue2 must occur before the store-release. If the protectedValue2 read occurs here, then some other thread may modify it.

------------

Citation: LDAR and STLR from ARM64, which applies to "any memory access".

That, plus the synchronization effects of the two operations on the same address. It’s important to note that another thread which doesn’t access the same atomic with the appropriate ordering can observe an inconsistent state, even if it puts a full fence between each non-atomic operation (on architectures with weak memory models).