Warning: mysqli::__construct(): (HY000/1203): User howardkn already has more than 'max_user_connections' active connections in D:\Inetpub\vhosts\howardknight.net\al.howardknight.net\includes\artfuncs.php on line 21
Failed to connect to MySQL: (1203) User howardkn already has more than 'max_user_connections' active connections
Warning: mysqli::query(): Couldn't fetch mysqli in D:\Inetpub\vhosts\howardknight.net\al.howardknight.net\index.php on line 66
Article <vashj8$gpjk$1@dont-email.me>
Deutsch   English   Français   Italiano  
<vashj8$gpjk$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!.POSTED!not-for-mail
From: jseigh <jseigh_es00@xemaps.com>
Newsgroups: comp.lang.c++
Subject: Re: Futexes ain't fast
Date: Fri, 30 Aug 2024 09:31:20 -0400
Organization: A noiseless patient Spider
Lines: 16
Message-ID: <vashj8$gpjk$1@dont-email.me>
References: <van414$3fe9t$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: Fri, 30 Aug 2024 15:31:21 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="35316df523afaaa9f2ce697a01f0eaa9";
	logging-data="550516"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/vGa0DcAJhxiHKFvCv+f3Y"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:lHWoNWBcQcXgothna6bjXJabGJU=
Content-Language: en-US
In-Reply-To: <van414$3fe9t$1@raubtier-asyl.eternal-september.org>
Bytes: 1715

On 8/28/2024 8: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:
> 

They don't have to be fast, they just have to allow correct synchronization
and allow performant fast paths.  Can the api be improved for the latter?
Certainly yes.  It is an awkward api to use.

Joe Seigh