Sujet : Re: smrproxy v2
De : jseigh_es00 (at) *nospam* xemaps.com (jseigh)
Groupes : comp.lang.c++Date : 04. Nov 2024, 13:46:37
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <vgafnd$uhgj$1@dont-email.me>
References : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
User-Agent : Mozilla Thunderbird
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.
smrproxy v2
Re: smrproxy v2