Path: news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>
Newsgroups: comp.lang.c++
Subject: Re: signalling a condvar from inside vs. signalling a condvar von
 outside
Date: Thu, 24 Apr 2025 12:59:17 -0700
Organization: A noiseless patient Spider
Lines: 36
Message-ID: <vue56m$292h9$1@dont-email.me>
References: <vte0g6$pmgv$1@raubtier-asyl.eternal-september.org>
 <vtpcnt$384n4$1@dont-email.me>
 <vtpu86$3qnsh$1@raubtier-asyl.eternal-september.org>
 <vtq3dt$3vg77$1@dont-email.me>
 <vtqo57$hi7r$1@raubtier-asyl.eternal-september.org>
 <vtrf3u$15mgp$1@dont-email.me>
 <vtsph1$2d55o$1@raubtier-asyl.eternal-september.org>
 <vtu9un$3mhje$1@dont-email.me>
 <vtub8i$3o27s$1@raubtier-asyl.eternal-september.org>
 <nPOMP.335105$j2D.258162@fx09.iad>
 <vu0f8m$1nm7v$2@raubtier-asyl.eternal-september.org>
 <eVVMP.1467426$BrX.929148@fx12.iad> <vu3obr$kp0a$2@dont-email.me>
 <vu4j24$1fq9b$1@raubtier-asyl.eternal-september.org>
 <vu6nrs$3b29s$1@dont-email.me>
 <vu78mg$3t3v4$1@raubtier-asyl.eternal-september.org>
 <vu925c$1esv8$1@dont-email.me>
 <vu9ss2$2a4at$1@raubtier-asyl.eternal-september.org>
 <vubds6$3oi9q$1@dont-email.me>
 <vudqqk$20hev$1@raubtier-asyl.eternal-september.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Thu, 24 Apr 2025 21:59:21 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="9ab23ff6e21fe9bbc243a2a98cfc6588";
	logging-data="2394665"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19EzJetmwSseMf+pw+7zvKIduObyiVKs98="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:8XHn0KY3cmZX9ayBRtVAnbZW0ZY=
Content-Language: en-US
In-Reply-To: <vudqqk$20hev$1@raubtier-asyl.eternal-september.org>

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.