Re: signalling a condvar from inside vs. signalling a condvar von outside

Am 24.04.2025 um 21:59 schrieb Chris M. Thomasson:

On 4/24/2025 10:02 AM, Bonita Montero wrote:

Am 23.04.2025 um 21:08 schrieb Chris M. Thomasson:
>

For trying to scale mutexes? Look up clever mutex solutions vs, say, RCU. They bite the dust.

>
A mutex and a condvar is for producer-consumer-relationships;
there's no way to handle that with RCU.

 Are you 100% sure about that?
 

And I've written a shared_obj<>-class, which is similar to shared_ptr<>
and a thsared_obj<>, which is similar to an atomic<shared_ptr<>>. The
latter uses a mutex but the pointer to the actual object is an atomic
pointer. Before doing any locking while assigning a tshared_obj<> to
a shared_obj<> I simply compare the pointer in the shared_obj<> with
the pointer in the thared_obj<>, where the latter is loaded lazyly
with relaxed_memory_order. As with RCU-like patterns the central
tshared_obj<> is rarely updated but frequently compared in the men-
tioned way. Only when the compare fails and the central tshared_obj<>
has become poiting to a different object the mutex is locked. The most
likely case that both pointers are equal takes only 1,5 nanoseconds on
my computer; no need for tricks like URCU and I guess my solution is
more efficient since the update is just several instructions and all
participating cachelines stay in shared mode accross all cores to
there's almost no interconnect-traffic.
>

 Are you delusional? Well, you did say "I guess". So, perhaps not.

1.5ns are only a few instruction; I guess that makes nearly no or
absolutely no difference against a URCU-solution.

Are you familiar with differential counting? No mutex involved. Btw, if you think that URCU needs to be reference counted in any way, you are wrong. I have no time right now to get into it, but shit happens.
 Sigh.