Path: ...!weretis.net!feeder9.news.weretis.net!news.nk.ca!rocksolid2!i2pn2.org!.POSTED!not-for-mail
From: mitchalsup@aol.com (MitchAlsup1)
Newsgroups: comp.arch
Subject: Re: Memory ordering
Date: Thu, 19 Dec 2024 18:33:36 +0000
Organization: Rocksolid Light
Message-ID: <ad8ce8000ff1a5a708d3cca330b5861e@www.novabbs.org>
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> <virlki$1fhli$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: i2pn2.org;
	logging-data="3663762"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="o5SwNDfMfYu6Mv4wwLiW6e/jbA93UAdzFodw5PEa6eU";
User-Agent: Rocksolid Light
X-Rslight-Site: $2y$10$RiRM6k5A2sWzqCXhZWrEieWmwKfO.oMwtCLx2RdvG1d0GfLUc8zD6
X-Spam-Checker-Version: SpamAssassin 4.0.0
X-Rslight-Posting-User: cb29269328a20fe5719ed6a1c397e21f651bda71
Bytes: 3882
Lines: 55

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.

> :^)
>
> Did I miss anything? Sorry Joe.