Path: news.eternal-september.org!eternal-september.org!raubtier-asyl.eternal-september.org!.POSTED!not-for-mail
From: Bonita Montero <Bonita.Montero@gmail.com>
Newsgroups: comp.lang.c++
Subject: Re: signalling a condvar from inside vs. signalling a condvar von
 outside
Date: Thu, 24 Apr 2025 23:11:57 +0200
Organization: A noiseless patient Spider
Lines: 42
Message-ID: <vue9dm$2dodm$3@raubtier-asyl.eternal-september.org>
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>
 <vue56m$292h9$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Thu, 24 Apr 2025 23:11:18 +0200 (CEST)
Injection-Info: raubtier-asyl.eternal-september.org; posting-host="b7129f90802d245507a0326744fce33d";
	logging-data="2548150"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18M4jdmHjaYMuOAZGAcguwwpGtC3wWxaTE="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:h5r8Mt5A7sIYXx1AD/IfS2Qn06g=
Content-Language: de-DE
In-Reply-To: <vue56m$292h9$1@dont-email.me>

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.