Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: "Chris M. Thomasson" Newsgroups: comp.lang.c++ Subject: Re: Futexes ain't fast Date: Wed, 28 Aug 2024 11:52:13 -0700 Organization: A noiseless patient Spider Lines: 21 Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Wed, 28 Aug 2024 20:52:14 +0200 (CEST) Injection-Info: dont-email.me; posting-host="2c8646cb91d7ff00a258e5443d55288c"; logging-data="3770138"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18wCSiKRw23mUcBUD8IuWs9NlGJuFYVs84=" User-Agent: Mozilla Thunderbird Cancel-Lock: sha1:js/MQlTlyEF1XPA/obj5gvT2mHo= Content-Language: en-US In-Reply-To: Bytes: 2126 On 8/28/2024 5:09 AM, Bonita Montero wrote: > I tested the operating-system specific mutex (CRITICAL_SECTION Or > pthread_mutext_t) against a futex and a std::mutex. I guessed std::mutex > uses th operating system specific mutex internally, but the times varied > so much across Windows and Linux that I gues that std::mutex used at > least a differently parametrized operating system mutex or maybe even > completely own code. > This are the times and each line has a further contender: [...] >             while( futex.exchange( true, memory_order_acquire ) ) >                 futex.wait( true, memory_order_relaxed ); >             futex.exchange( false, memory_order_release ); >             futex.notify_one(); >         } ); [...] A wait bit would help out here... ;^) Afaict, this is a rather "naive" use of futexes. In you use case here, the exchange to unlock can be a simple atomic store with release semantics. Also, try to think about calling notify_* only when you absolutely need to... :^)