Path: ...!weretis.net!feeder9.news.weretis.net!news.quux.org!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.lang.c++
Subject: Re: smrproxy v2
Date: Thu, 12 Dec 2024 00:43:23 -0800
Organization: A noiseless patient Spider
Lines: 49
Message-ID: <vje7nc$21j2c$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>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 12 Dec 2024 09:43:25 +0100 (CET)
Injection-Info: dont-email.me; posting-host="f93bbc66b245220591954ac68052dc13";
	logging-data="2149452"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+ftx7Oei4LWQRopgiph3MEtkBj1xghwHk="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:UqqwhGF35NNzEshVapVVsaH6D9M=
Content-Language: en-US
In-Reply-To: <vgafnd$uhgj$1@dont-email.me>
Bytes: 3551

On 11/4/2024 4:46 AM, jseigh wrote:
> 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.  

Hummm... If I remember correctly, you said something about using a 
simple atomic exchange to pop a whole list (lock-free stack), then 
simple reversing the list to get a fifo order? Do you remember any of 
that way back on c.p.t?



> 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.
> 
> 
>