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: Is Intel exceptionally unsuccessful as an architecture
 =?UTF-8?B?ZGVzaWduZXI/?=
Date: Mon, 23 Sep 2024 22:32:36 +0000
Organization: Rocksolid Light
Message-ID: <b23480c6afdce45b31fb9ae2e2397846@www.novabbs.org>
References: <memo.20240913205156.19028s@jgd.cix.co.uk> <20240918190027.00003e4e@yahoo.com> <vcfp2q$8glq$5@dont-email.me> <jwv34lumjz7.fsf-monnier+comp.arch@gnu.org> <vckpkg$18k7r$2@dont-email.me> <vckqus$18j12$2@dont-email.me> <920c561c4e39e91d3730b6aab103459b@www.novabbs.org> <vcl6i6$1ad9e$1@dont-email.me> <d3b9fc944f708546e4fbe5909c748ba3@www.novabbs.org> <%dAHO.54667$S9Vb.39628@fx45.iad> <vcna56$1nlod$2@dont-email.me> <a7708487530552a53732070fe08d9458@www.novabbs.org> <vcprkv$2asrd$1@dont-email.me> <e2c993172c11a221c4dcb9973f9cdb86@www.novabbs.org> <vcqe6f$2d8oa$1@dont-email.me> <4f84910a01d7db353eedadd7c471d7d3@www.novabbs.org> <20240923105336.0000119b@yahoo.com> <6577e60bd63883d1a7bd51c717531f38@www.novabbs.org> <vcsmvq$2s1qd$2@dont-email.me> <23d9473740db6c0ecc7e1d4a2179c75e@www.novabbs.org> <vcsphq$2sh9d$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="3207048"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="65wTazMNTleAJDh/pRqmKE7ADni/0wesT78+pyiDW8A";
User-Agent: Rocksolid Light
X-Rslight-Site: $2y$10$90lEnDVn/BxREo/dQeptXuB20/j/OJnLRQ5PXIHFKo81qlCdoowQu
X-Rslight-Posting-User: ac58ceb75ea22753186dae54d967fed894c3dce8
X-Spam-Checker-Version: SpamAssassin 4.0.0
Bytes: 4750
Lines: 66

On Mon, 23 Sep 2024 22:19:37 +0000, Chris M. Thomasson wrote:

> On 9/23/2024 2:58 PM, MitchAlsup1 wrote:
>> On Mon, 23 Sep 2024 21:35:53 +0000, Chris M. Thomasson wrote:
>>> Iirc, been a while, I think there was a problem on one of the Pentiums,
>>> might be the pro, where it had an issue with releasing a spinlock with a
>>> normal store. I am most likely misremembering, but it is sparking some
>>> strange memories. Way back on c.p.t, Alex Terekhov (hope I did not
>>> butcher the spelling of his name), anyway, wrote about it, I think...
>>> Way back. early 2000's I think.
>>
>> Many ATOMIC sequences start or end without any note on the memory
>> reference that it bounds an ATOMIC event. CAS has this problem
>> on the value to ultimately be compared (the start), T&S has this
>> problem on ST that unlocks the lock (the end). It is like using
>> indentation as the only means of signaling block structure in
>> your language of choice.
>
> _Strong_ CAS in C++ terms, ala cmpxchg, will only fail if the comparands
> are different.

And used improperly is subject to ABA problem.

However, if the LD which obtained the value to be compared was
KNOWN to be part of an ATOMIC sequence ending with CAS, one can
eliminate the ABA problem for all <reasonable> CAS sequences.

>                This can be implemented with LL/SC for sure.

With the addition above.

>                                                             Scott
> mentioned something about a bus lock after a certain amount of
> failures... (side note) Weak CAS can fail even if the comparands are
> identical to each other ala LL/SC. This reminds me of LL/SC. the ABA
> problem can worked around and/or eliminated without using LL/SC. I
> remember reading papers about LL/SC getting around ABA, but then read
> about how they can have their own can of worms. Pessimistic vs
> optimistic sync... Wait/ Lock / Obstruction free things... ;^)

You are the expert on that here.

> Fwiw, getting rid of the StoreLoad membar in algorithms like SMR is
> great. There is a way to do this in existing systems. So, no hardware
> changes required, and makes the system run fast.

I got rid of all MemBars and still have a fairly relaxed memory model.

> Think of allowing a rouge thread to pound a CAS with random data wrt the
> comparand, trying to get it to fail... Of course this can be modifying a
> reservation granule wrt LL/SC side of things, right? Pessimistic (CAS)
> vs Optimistic (LL/SC)?

Or methodological (ESM).

>
>
>
>>
>> Both are bad practice in making HW that can perform these things
>> efficiently. But notice that LL-SC does not have this problem.
>> Neither does ESM.
>>
>>>>> According to my understanding, what matters is # of CPU cores with
>>>>> coherent access to the same memory+IO.
>>>>> For x86, 4 cores (CPUs) were relatively common since 1996. There
>>>>> existed few odd 8-core systems too, still back in the last century.