Re: smrproxy v2

Liste des GroupesRevenir à cl c++ 
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.


Date Sujet#  Auteur
17 Oct 24 * smrproxy v266jseigh
17 Oct 24 +* Re: smrproxy v241Chris M. Thomasson
17 Oct 24 i`* Re: smrproxy v240jseigh
18 Oct 24 i `* Re: smrproxy v239Chris M. Thomasson
18 Oct 24 i  +* Re: smrproxy v22Chris M. Thomasson
18 Oct 24 i  i`- Re: smrproxy v21Chris M. Thomasson
18 Oct 24 i  `* Re: smrproxy v236jseigh
26 Oct 24 i   `* Re: smrproxy v235Chris M. Thomasson
26 Oct 24 i    `* Re: smrproxy v234jseigh
27 Oct 24 i     `* Re: smrproxy v233Chris M. Thomasson
28 Oct 24 i      `* Re: smrproxy v232jseigh
28 Oct 24 i       +* Re: smrproxy v228Chris M. Thomasson
28 Oct 24 i       i`* Re: smrproxy v227jseigh
28 Oct 24 i       i `* Re: smrproxy v226Chris M. Thomasson
28 Oct 24 i       i  `* Re: smrproxy v225jseigh
28 Oct 24 i       i   `* Re: smrproxy v224Chris M. Thomasson
29 Oct 24 i       i    +- Re: smrproxy v21Chris M. Thomasson
29 Oct 24 i       i    `* Re: smrproxy v222jseigh
29 Oct 24 i       i     +* Re: smrproxy v23Chris M. Thomasson
29 Oct 24 i       i     i`* Re: smrproxy v22jseigh
29 Oct 24 i       i     i `- Re: smrproxy v21Chris M. Thomasson
29 Oct 24 i       i     +* Re: smrproxy v25Chris M. Thomasson
29 Oct 24 i       i     i`* Re: smrproxy v24jseigh
29 Oct 24 i       i     i `* Re: smrproxy v23Chris M. Thomasson
30 Oct 24 i       i     i  `* Re: smrproxy v22jseigh
1 Nov 24 i       i     i   `- Re: smrproxy v21Chris M. Thomasson
29 Oct 24 i       i     `* Re: smrproxy v213Chris M. Thomasson
30 Oct 24 i       i      `* Re: smrproxy v212Chris M. Thomasson
30 Oct 24 i       i       `* Re: smrproxy v211jseigh
4 Nov 24 i       i        `* Re: smrproxy v210Chris M. Thomasson
4 Nov 24 i       i         `* Re: smrproxy v29jseigh
4 Nov 24 i       i          +* Re: smrproxy v23Muttley
4 Nov 24 i       i          i`* Re: smrproxy v22Chris M. Thomasson
9 Nov 24 i       i          i `- Re: smrproxy v21Chris M. Thomasson
12 Dec 24 i       i          `* Re: smrproxy v25Chris M. Thomasson
12 Dec 24 i       i           `* Re: smrproxy v24jseigh
12 Dec 24 i       i            `* Re: smrproxy v23Chris M. Thomasson
13 Dec 24 i       i             `* Re: smrproxy v22jseigh
26 Dec 24 i       i              `- Re: smrproxy v21Chris M. Thomasson
28 Oct 24 i       `* Re: smrproxy v23Chris M. Thomasson
28 Oct 24 i        +- Re: smrproxy v21Chris M. Thomasson
28 Oct 24 i        `- Re: smrproxy v21Chris M. Thomasson
29 Oct 24 +* Re: smrproxy v24Chris M. Thomasson
30 Oct 24 i+- Re: smrproxy v21Chris M. Thomasson
30 Oct 24 i`* Re: smrproxy v22Chris M. Thomasson
30 Oct 24 i `- Re: smrproxy v21Chris M. Thomasson
30 Oct 24 +* Re: smrproxy v22Chris M. Thomasson
30 Oct 24 i`- Re: smrproxy v21jseigh
2 Nov 24 +- Re: smrproxy v21Chris M. Thomasson
21 Nov 24 `* Re: smrproxy v217jseigh
23 Nov 24  `* Re: smrproxy v216jseigh
23 Nov 24   +* Re: smrproxy v23Chris M. Thomasson
24 Nov 24   i`* Re: smrproxy v22jseigh
24 Nov 24   i `- Re: smrproxy v21Chris M. Thomasson
24 Nov 24   `* Re: smrproxy v212jseigh
25 Nov 24    +* Re: smrproxy v27Chris M. Thomasson
25 Nov 24    i`* Re: smrproxy v26jseigh
25 Nov 24    i +* Re: smrproxy v22Chris M. Thomasson
25 Nov 24    i i`- Re: smrproxy v21Chris M. Thomasson
25 Nov 24    i `* Re: smrproxy v23Chris M. Thomasson
25 Nov 24    i  `* Re: smrproxy v22jseigh
26 Nov 24    i   `- Re: smrproxy v21Chris M. Thomasson
27 Nov 24    `* Re: smrproxy v24jseigh
9 Dec 24     `* Re: smrproxy v23jseigh
11 Dec 24      `* Re: smrproxy v22jseigh
12 Dec 24       `- Re: smrproxy v21Chris M. Thomasson

Haut de la page

Les messages affichés proviennent d'usenet.

NewsPortal