Article <vat7ft$k5je$7@dont-email.me>

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 <vat7ft$k5je$7@dont-email.me>

Deutsch English Français Italiano

<vat7ft$k5je$7@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: "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>
Newsgroups: comp.lang.c++
Subject: Re: Futexes ain't fast
Date: Fri, 30 Aug 2024 12:45:01 -0700
Organization: A noiseless patient Spider
Lines: 17
Message-ID: <vat7ft$k5je$7@dont-email.me>
References: <van414$3fe9t$1@raubtier-asyl.eternal-september.org>
 <vashj8$gpjk$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 30 Aug 2024 21:45:02 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="52205d2e02d95465ac4101a55f1e89ed";
	logging-data="661102"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18qjZP4WYey1V9pU7H7pXnYVDy95ii2tQk="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:gF4id0omD/JF/3BMlUTEkMIhwPU=
In-Reply-To: <vashj8$gpjk$1@dont-email.me>
Content-Language: en-US
Bytes: 1852

On 8/30/2024 6:31 AM, jseigh wrote:
> 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.

100% agreed. Eventcounts are in the mix as well.