Path: ...!eternal-september.org!feeder2.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: jseigh <jseigh_es00@xemaps.com>
Newsgroups: comp.lang.c++
Subject: Re: smrproxy v2
Date: Mon, 4 Nov 2024 07:46:37 -0500
Organization: A noiseless patient Spider
Lines: 38
Message-ID: <vgafnd$uhgj$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>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 04 Nov 2024 13:46:37 +0100 (CET)
Injection-Info: dont-email.me; posting-host="471621c5f89de29125c801eaeebcace1";
	logging-data="1000979"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1//wHIo8Mrwh5YsggzEVqgC"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:hwyPYLj203PNxqfRDC1sJXJUlUE=
Content-Language: en-US
In-Reply-To: <vg9l7u$q3ee$3@dont-email.me>
Bytes: 3096

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.