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: Arguments for a sane ISA 6-years later
Date: Tue, 30 Jul 2024 13:26:14 -0700
Organization: A noiseless patient Spider
Lines: 46
Message-ID: <v8bi97$15rb6$4@dont-email.me>
References: <b5d4a172469485e9799de44f5f120c73@www.novabbs.org>
 <v7ubd4$2e8dr$1@dont-email.me> <v7uc71$2ec3f$1@dont-email.me>
 <2024Jul26.190007@mips.complang.tuwien.ac.at> <v872h5$alfu$2@dont-email.me>
 <v87g4i$cvih$1@dont-email.me> <v88oid$jkah$1@dont-email.me>
 <v8bgmq$15b0p$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Tue, 30 Jul 2024 22:26:15 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="87f39ac7600a900f46d6fc02404b3288";
	logging-data="1240422"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18JQFmfUJqRB6kM+WU013YsKhfkljfl42I="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:DZ8Wm3mQNehy5BwyIuXKyx5ztzg=
In-Reply-To: <v8bgmq$15b0p$1@dont-email.me>
Content-Language: en-US
Bytes: 3356

On 7/30/2024 12:59 PM, jseigh wrote:
> On 7/29/2024 2:55 PM, Chris M. Thomasson wrote:
> 
>> However... There is "special" mutex logic that actually requires a 
>> #StoreLoad! Peterson's algorithm for example. Iirc, it needs a 
>> #StoreLoad because it depends on a store followed by a load to another 
>> location to hold true. This is a bit different than other locking 
>> algorithms...
>>
>> There there are more "exotic" methods such as so-called asymmetric 
>> mutexes. They can have fast paths and slow paths, so to speak. It's 
>> almost getting into the realm of RCU here... A fast path can be memory 
>> barrier free. The slow path can make things consistent with the use of 
>> so called "remote" memory barriers. It's funny that Windows seems to 
>> have one:
>>
>> https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-flushprocesswritebuffers
>>
>> ;^)
>>
>> The slow path is meant to not be frequently used, hence the term 
>> asymmetric. On par with read/write logic... :^)
>>
> 
> The folly library hazard pointers use that on windows,  membarrier() 
> system call on linux (something else on older linuxes), to get rid of 
> the expensive store/load memory barrier in hazard pointer loads.

I need to check that out; thanks for the heads up. Fwiw, remember that 
old thread on comp.programming.threads where you first'ish published 
your ideas on RCU+SMR? I need to see if the folly library references 
your work. Also, remember when some paper from SUN or something was 
trying to claim your atomic_ptr logic? Iirc, we talked about it back on 
comp.arch, a long time ago...

I remember you issued a "challenge like" post over on 
comp.programming.threads wrt detecting quiescent periods. Iirc, I was 
the first one to comment wrt a possible hackish solution using timing 
wrt kernel time. ;^)


> Something like 0.7 nsecs w/o membar vs 7.7 w/ membar.  The term I've 
> seen being used now is asymmetric memory barrier.

Big time! This is bringing back a lot of memories Joe. :^) Thanks.