Path: news.eternal-september.org!eternal-september.org!raubtier-asyl.eternal-september.org!.POSTED!not-for-mail From: Bonita Montero 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: References: 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: 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>. 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.