Re: Memory ordering

On 12/5/24 02:44, 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. !
 :^)
 Did I miss anything? Sorry Joe.
 

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.
Joe Seigh