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