Path: ...!eternal-september.org!feeder2.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>
Newsgroups: comp.lang.c++
Subject: Re: smrproxy v2
Date: Sat, 9 Nov 2024 13:51:26 -0800
Organization: A noiseless patient Spider
Lines: 77
Message-ID: <vgolgt$3vr0c$3@dont-email.me>
References: <vequrc$2o7qc$1@dont-email.me> <verr04$2stfq$1@dont-email.me>
 <verubk$2t9bs$1@dont-email.me> <ves78h$2ugvm$2@dont-email.me>
 <vetj1f$39iuv$1@dont-email.me> <vfh4dh$3bnuq$1@dont-email.me>
 <vfh7mg$3c2hs$1@dont-email.me> <vfm4iq$ill4$1@dont-email.me>
 <vfmesn$k6mn$1@dont-email.me> <vfmf21$kavl$1@dont-email.me>
 <vfmm9a$lob3$1@dont-email.me> <vfn2di$r8ca$1@dont-email.me>
 <vfntgb$vete$1@dont-email.me> <vfp1c3$16d9f$1@dont-email.me>
 <vfpd43$186t4$1@dont-email.me> <vfpp18$1dqvu$3@dont-email.me>
 <vfrm7s$1np4q$3@dont-email.me> <vftnga$27k8k$2@dont-email.me>
 <vg9l7u$q3ee$3@dont-email.me> <vgafnd$uhgj$1@dont-email.me>
 <vgaki9$vn6q$1@dont-email.me> <vgbbkd$141v1$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sat, 09 Nov 2024 22:51:26 +0100 (CET)
Injection-Info: dont-email.me; posting-host="42a0198f79e20e1c99d0f1a5c57bc090";
	logging-data="4189196"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19lrHQZVkwpHonlly+EWZrew+HnD8qV9Sg="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:9XK5VtARWEX/G9iI7I1PnqMGbzA=
Content-Language: en-US
In-Reply-To: <vgbbkd$141v1$1@dont-email.me>
Bytes: 4505

On 11/4/2024 12:42 PM, Chris M. Thomasson wrote:
> On 11/4/2024 6:09 AM, Muttley@DastartdlyHQ.org wrote:
>> On Mon, 4 Nov 2024 07:46:37 -0500
>> jseigh <jseigh_es00@xemaps.com> boring babbled:
>>> On 11/4/24 00:14, Chris M. Thomasson wrote:
>>>> On 10/30/2024 9:39 AM, jseigh wrote:
>>>>> On 10/29/24 18:05, Chris M. Thomasson wrote:
>>>>>> On 10/28/2024 9:41 PM, Chris M. Thomasson wrote:
>>>>>
>>>>>>
>>>>>> Ahhh, if you are using an async membar in your upcoming C++ version,
>>>>>> then it would be fine. No problem. A compiler fence ala
>>>>>> atomic_signal_fence, and the the explicit release, well, it will
>>>>>> work. I don't see why it would not work.
>>>>>>
>>>>>> For some reason, I thought you were going to not use an async membar
>>>>>> in your C++ version. Sorry. However, it still would be fun to test
>>>>>> against... ;^)
>>>>>
>>>>> The C version has both versions.  The C++ version does only the
>>>>> async member version.  But I'm not publishing that code so it's
>>>>> a moot point.
>>>>
>>>> I got side tracked with more heavy math. The problem with C++ code that
>>>> uses an async memory barrier is that its automatically rendered into a
>>>> non-portable state... Yikes! Imvvvvvho, C/C++ should think about
>>>> including them in some future standard. It would be nice. Well, for us
>>>> at least! ;^)
>>>
>>> That's never going to happen.  DWCAS has been around for more than
>>> 50 years and c++ doesn't support that and probably never will.
>>> You can't write lock-free queues that are ABA free and
>>> are performant without that.  So async memory barriers won't
>>> happen any time soon either.
>>>
>>> Long term I think c++ will fade into irrelevance along with
>>> all the other programming languages based on an imperfect
>>> knowledge of concurrency, which is basically all of them
>>> right now.
>>
>> Given most concurrent operating systems are written in these "imperfect"
>> languages how does that square with your definition? And how would your
>> perfect language run on them?
>>
>> Anyway, concurrency is the job of the OS, not the language. C++ 
>> threading is
>> just a wrapper around pthreads on *nix and windows threads on Windows. 
>> The
>> language just needs an interface to the underlying OS functionality, 
>> it should
>> not try and implement the functionality itself as it'll always be a hack.
>>
> 
> A start would be C++ having an "always lock free" CAS for two contiguous 
> words on systems that support it, yes, even 64 bit. ala:
> 
> struct anchor {
>      word a;
>      word b;
> };

Even better:

struct anchor {
     void* a;
     word b;
};

where sizeof(void*) = sizeof(word)... ;^)

> 
> cmpxchg8b for x86, cmpxchg16b for x64, ect...
> 
> https://www.felixcloutier.com/x86/cmpxchg8b:cmpxchg16b
> 
>