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: Is Intel exceptionally unsuccessful as an architecture designer?
Date: Mon, 23 Sep 2024 11:33:01 -0400
Organization: A noiseless patient Spider
Lines: 45
Message-ID: <vcs1ne$2omku$2@dont-email.me>
References: <memo.20240913205156.19028s@jgd.cix.co.uk>
 <vcda96$3p3a7$2@dont-email.me>
 <21028ed32d20f0eea9a754fafdb64e45@www.novabbs.org>
 <RECGO.45463$xO0f.22925@fx48.iad> <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>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Mon, 23 Sep 2024 17:33:02 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="469a7820058845a3b597fefa81415f01";
	logging-data="2906782"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19obOrmd7QZWngvAnsL7gmr"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:xkH+zbF+OyR1fw8tmxJ2gWXhESw=
Content-Language: en-US
In-Reply-To: <4f84910a01d7db353eedadd7c471d7d3@www.novabbs.org>
Bytes: 3333

On 9/22/24 21:34, MitchAlsup1 wrote:
> On Mon, 23 Sep 2024 0:53:35 +0000, jseigh wrote:
> 

> 
>> As far as loads and stores go, if they are atomic then
>> a load will not see a value that was not from some store.
> 
> When you include stores from devices into memory, we agree.
> A LD should return the last written value.
> 
> When you include device control registers; all bets are off.
> 
>> Regarding memory barriers, that depends on the hardware
>> memory model and the program logic assuming one knows
>> how to do concurrent algorithms.
> 
> In particular, we are talking about a sequence of instructions
> with the properties:: a) an external observer can see only
> the previous or new values of a concurrent data structure
> and none of the intermediate changes, and b) should the
> event fail somewhere in the middle, no-one saw any of
> the intermediate state, either.
> 
> The event is bigger than the memory reference instruction.
> 
> And finally, getting the MemBarIzation correct seems to
> be beyond many-most programmers leading to error prone
> applications.
> 

I have a pretty good understanding of atomicity and memory
models so all good there.

Are you familiar with RCU and how it's used in the linux
kernel?  RCU locked reads of data structures are not
atomic. Works fine if you know how to do lock-free
data structures.

RCU is a form of qsbr.  I did a qsbr implementation in
the 80's at IBM and we got a patent for it, 4,809,168.
A lot of other stuff as well, so like I said, all good.

Joe Seigh