Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>
Newsgroups: comp.arch
Subject: Re: Memory ordering
Date: Wed, 4 Dec 2024 23:44:19 -0800
Organization: A noiseless patient Spider
Lines: 50
Message-ID: <virlki$1fhli$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> <vipv2t$v57m$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 05 Dec 2024 08:44:19 +0100 (CET)
Injection-Info: dont-email.me; posting-host="8b58a9dc3a65076c35b5d9b05ba357b4";
	logging-data="1558194"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/WseZ+Qqp6RmEB5gNuU1Fvr3CPErmuXcw="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:gkn9w9HLRmxm7CsSPHF8+X4Mnac=
In-Reply-To: <vipv2t$v57m$1@dont-email.me>
Content-Language: en-US
Bytes: 3618

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.