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

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