Sujet : Re: smrproxy v2
De : Muttley (at) *nospam* DastartdlyHQ.org
Groupes : comp.lang.c++Date : 04. Nov 2024, 15:09:14
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <vgaki9$vn6q$1@dont-email.me>
References : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
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.