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: Mon, 4 Nov 2024 12:42:53 -0800
Organization: A noiseless patient Spider
Lines: 62
Message-ID: <vgbbkd$141v1$1@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>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 04 Nov 2024 21:42:54 +0100 (CET)
Injection-Info: dont-email.me; posting-host="a3560c29bf30eac6bd9d64bfc512bec5";
	logging-data="1181665"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+nT62dbrtPGPjBRe90pBwQNEPZou0lF8M="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:0TpKKT67Cwjxbqr08tisdCgHZKg=
Content-Language: en-US
In-Reply-To: <vgaki9$vn6q$1@dont-email.me>
Bytes: 4209

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;
};

cmpxchg8b for x86, cmpxchg16b for x64, ect...

https://www.felixcloutier.com/x86/cmpxchg8b:cmpxchg16b