Re: Arguments for a sane ISA 6-years later

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.