Deutsch   English   Français   Italiano  
<vu925c$1esv8$1@dont-email.me>

View for Bookmarking (what is this?)
Look up another Usenet article

Path: ...!eternal-september.org!feeder3.eternal-september.org!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: Tue, 22 Apr 2025 14:36:44 -0700
Organization: A noiseless patient Spider
Lines: 26
Message-ID: <vu925c$1esv8$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>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Tue, 22 Apr 2025 23:36:45 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="6376ede71f141445523a87c1f6d34768";
	logging-data="1537000"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/SWaYhggkLXmJm7VMkHU16iash9qnRMtc="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:9RZpLhF9gYNp6pVIUx6AF6xRmLw=
Content-Language: en-US
In-Reply-To: <vu78mg$3t3v4$1@raubtier-asyl.eternal-september.org>
Bytes: 3131

On 4/21/2025 10:16 PM, Bonita Montero wrote:
> Am 22.04.2025 um 02:28 schrieb Chris M. Thomasson:
> 
>> That makes no sense? Wait Morphing Doesn't Guarantee Elimination of 
>> the Thundering Herd...
> 
> Of course wait morphing helps here because with WM only one thread
> sees the mutex unlocked and not n threads.

It was created to try to _help_ with thundering herd. There can be some 
interesting issues... Think of pushing 12 items in the queue, broadcast 
inside the mutex, then 42 threads go onto the morph list. Depending on 
implementation, any new threads will not be able to acquire the mutex 
until those 42 threads are out of the morph. This can be bad for several 
reasons... If a thread is in the morph its in line waiting for it... So, 
it's a bit screwed and can't do anything else. If another thread can 
acquire the mutex before the morph is done, then it's basically 
thundering heard all over again. Fwiw, trying to scale mutexes is sort 
of odd anyway. We can make the best mutex ever, but they have trouble 
scaling.

Now, there is an interesting usage pattern I made a while back wrt 
falling back for a thread to do something else without waiting on a 
locked mutex. I posted some info about it before. It's akin to an 
adaptive mutex, however, instead of spinning, we can choose do other 
work, if its available...