Re: smrproxy v2

On 11/4/2024 12:42 PM, Chris M. Thomasson wrote:

On 11/4/2024 6:09 AM, Muttley@DastartdlyHQ.org wrote:

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

 A start would be C++ having an "always lock free" CAS for two contiguous words on systems that support it, yes, even 64 bit. ala:
 struct anchor {
     word a;
     word b;
};

Even better:
struct anchor {
     void* a;
     word b;
};
where sizeof(void*) = sizeof(word)... ;^)

 cmpxchg8b for x86, cmpxchg16b for x64, ect...
 https://www.felixcloutier.com/x86/cmpxchg8b:cmpxchg16b