Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: jseigh <jseigh_es00@xemaps.com>
Newsgroups: comp.arch
Subject: Re: Memory ordering
Date: Wed, 4 Dec 2024 11:13:17 -0500
Organization: A noiseless patient Spider
Lines: 39
Message-ID: <vipv2t$v57m$1@dont-email.me>
References: <vfono1$14l9r$1@dont-email.me> <vh4530$2mar5$1@dont-email.me>
 <-rKdnTO4LdoWXKj6nZ2dnZfqnPWdnZ2d@supernews.com>
 <vh5t5b$312cl$2@dont-email.me>
 <5yqdnU9eL_Y_GKv6nZ2dnZfqn_GdnZ2d@supernews.com>
 <2024Nov15.082512@mips.complang.tuwien.ac.at> <vh7ak1$3cm56$1@dont-email.me>
 <20241115152459.00004c86@yahoo.com> <vh8bn7$3j6ql$1@dont-email.me>
 <vhb2dc$73fe$1@dont-email.me> <vhct2q$lk1b$2@dont-email.me>
 <2024Nov17.161752@mips.complang.tuwien.ac.at> <vhh16e$1lp5h$1@dont-email.me>
 <2024Dec3.100144@mips.complang.tuwien.ac.at> <vin2rp$3ofc$1@dont-email.me>
 <3aa9f0a3d3dde86193abb1c01e52d03a@www.novabbs.org>
 <jwvser449xz.fsf-monnier+comp.arch@gnu.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Wed, 04 Dec 2024 17:13:18 +0100 (CET)
Injection-Info: dont-email.me; posting-host="37865afaa9225d3e4d6ffaa8bbe91511";
	logging-data="1021174"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+KYVpvqROesGTAelfxsoU8"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:c/9f/49I1xq+maj0YkOY5zbtJq8=
In-Reply-To: <jwvser449xz.fsf-monnier+comp.arch@gnu.org>
Content-Language: en-US
Bytes: 3080

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