Re: Memory ordering

On 12/19/2024 3:59 PM, MitchAlsup1 wrote:

On Thu, 19 Dec 2024 21:19:24 +0000, Chris M. Thomasson wrote:
 

On 12/19/2024 10:33 AM, MitchAlsup1 wrote:

On Thu, 5 Dec 2024 7:44:19 +0000, Chris M. Thomasson wrote:
>

On 12/4/2024 8:13 AM, jseigh wrote:

On 12/3/24 18:37, Stefan Monnier wrote:

                                           If there are places
in the code it doesn't know this can't happen it won't optimize
across it, more or less.

>
The problem is HOW to TELL the COMPILER that these memory references
are "more special" than normal--when languages give few mechanisms.

>
We could start with something like
>
     critical_region {
       ...
     }
>
such that the compiler must refrain from any code motion within
those sections but is free to move things outside of those sections as
if
execution was singlethreaded.
>

>
C/C++11 already defines what lock acquire/release semantics are.
Roughly you can move stuff outside of a critical section into it
but not vice versa.
>
Java uses synchronized blocks to denote the critical section.
C++ (the society for using RAII for everything) has scoped_lock
if you want to use RAII for your critical section.  It's not
always obvious what the actual critical section is.  I usually
use it inside its own bracket section to make it more obvious.
   { std::scoped_lock m(mutex);
     // .. critical section
   }
>
I'm not a big fan of c/c++ using acquire and release memory order
directives on everything since apart from a few situations it's
not intuitively obvious what they do in all cases.  You can
look a compiler assembler output but you have to be real careful
generalizing from what you see.

>
The release on the unlock can allow some following stores and things to
sort of "bubble up before it?
>
Acquire and release confines things to the "critical section", the
release can allow for some following things to go above it, so to speak.
This is making me think of Alex over on c.p.t. !

>
This sounds dangerous if the thing allowed to go above it is unCacheable
while the lock:release is cacheable, the cacheable lock can arrive at
another core before the unCacheable store arrives at its destination.

>
Humm... Need to ponder on that. Wrt the sparc:
>
membar #LoadStore | #StoreStore
>
can allow following stores to bubble up before it. If we want to block
that then we would use a #StoreLoad. However, a #StoreLoad is not
required for unlocking a mutex.

 It is the cacheable locks covering unCacheable data that got MOESI
protocol in trouble (SPARC V8 era). MESI does not have this kind
of problem. {{SuperSPARC MESI did not have this problem because
writes to memory (via SNOOP hits) were slow, Ross MOESI did have
this problem because cache-to-cache transfers (SNOOP hit) were as
few as 6 cycles.}}
 S O , What kind of barriers a relaxed memory model needs becomes
dependent on the cache coherency model !?!?!?! How is software
going to deal with that ?!? It them becomes dependent on the
memory order model, as a cascade of Oh-crap-what-have-I-done-to-
myself ...
 It is stuff like this that lead My 66000 to alter memory models
as it accesses memory and mandates that all critical sections
are denoted (.lock) at the beginning and end of the ATOMIC event.
Thus, the programmer gets the performance of the relaxed memory
with the sanity of sequential consistency without programmer
inivolvement.

Well, it depends on what you need to do. Iirc, even x86 has that WB, WC and WT memory. It has the lfence, sfence and mfence to handle it, non-temporal instructions. I cannot exactly remember all of it right now. acquire-release consistency is for MOV is the way. CLFLUSH? ;^)
I think there was a problem here, iirc something about Plan9 problem rings a bell. I need to refresh my mind. Thanks Mitch! :^)
Iirc, Alex Terekhov wrote about it way back on c.p.t.