Re: Memory ordering

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