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

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