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 23:59:01 +0000
Organization: Rocksolid Light
Message-ID: <9fac22de9841dbb36f26615dbc6432db@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> <ad8ce8000ff1a5a708d3cca330b5861e@www.novabbs.org> <vk22kr$31esr$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="3699617"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="o5SwNDfMfYu6Mv4wwLiW6e/jbA93UAdzFodw5PEa6eU";
User-Agent: Rocksolid Light
X-Rslight-Posting-User: cb29269328a20fe5719ed6a1c397e21f651bda71
X-Spam-Checker-Version: SpamAssassin 4.0.0
X-Rslight-Site: $2y$10$4FeRYd4gvrvaA5jwmFXvm.8Lpx9FJ7xt8rBfk6s/xnP/AbMwKRSwy
Bytes: 5376
Lines: 82

On Thu, 19 Dec 2024 21:19:24 +0000, Chris M. Thomasson wrote:

> On 12/19/2024 10:33 AM, MitchAlsup1 wrote:
>> 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.
>
> Humm... Need to ponder on that. Wrt the sparc:
>
> membar #LoadStore | #StoreStore
>
> can allow following stores to bubble up before it. If we want to block
> that then we would use a #StoreLoad. However, a #StoreLoad is not
> required for unlocking a mutex.

It is the cacheable locks covering unCacheable data that got MOESI
protocol in trouble (SPARC V8 era). MESI does not have this kind
of problem. {{SuperSPARC MESI did not have this problem because
writes to memory (via SNOOP hits) were slow, Ross MOESI did have
this problem because cache-to-cache transfers (SNOOP hit) were as
few as 6 cycles.}}

S O , What kind of barriers a relaxed memory model needs becomes
dependent on the cache coherency model !?!?!?! How is software
going to deal with that ?!? It them becomes dependent on the
memory order model, as a cascade of Oh-crap-what-have-I-done-to-
myself ...

It is stuff like this that lead My 66000 to alter memory models
as it accesses memory and mandates that all critical sections
are denoted (.lock) at the beginning and end of the ATOMIC event.
Thus, the programmer gets the performance of the relaxed memory
with the sanity of sequential consistency without programmer
inivolvement.