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: counting_semaphore question
Date: Thu, 12 Sep 2024 11:57:15 -0700
Organization: A noiseless patient Spider
Lines: 37
Message-ID: <vbvdib$c8gk$8@dont-email.me>
References: <vbrqjj$3hvsd$1@dont-email.me>
 <vbs01c$3j5mc$1@raubtier-asyl.eternal-september.org>
 <vbs0tm$3jf62$1@dont-email.me>
 <vbs1al$3jgnp$1@raubtier-asyl.eternal-september.org>
 <vbsvsr$3pr1c$2@dont-email.me>
 <vbtj6c$1js1$2@raubtier-asyl.eternal-september.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Thu, 12 Sep 2024 20:57:15 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="26dfebf598c361779a3e3249a41dbd07";
	logging-data="401940"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/AnHSHXNUVWq0tk1X69pnK5BHW93uShu8="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:CqW7Pl2pM5ptj5qiGhwa9YMbAi8=
Content-Language: en-US
In-Reply-To: <vbtj6c$1js1$2@raubtier-asyl.eternal-september.org>
Bytes: 2681

On 9/11/2024 7:21 PM, Bonita Montero wrote:
> Am 11.09.2024 um 22:51 schrieb Chris M. Thomasson:
>> On 9/11/2024 5:10 AM, Bonita Montero wrote:
>>> Am 11.09.2024 um 14:03 schrieb Muttley@dastardlyhq.com:
>>>
>>>> What upper limit? The max number of threads allowed in the protected 
>>>> section
>>>> above is 2, not 10. Or do you mean it'll only count up to 10 threads 
>>>> waiting
>>>> and ignore any beyond that? What happens if thread 11 comes along?
>>>
>>> The static parmeter is the maximum counter and the the two is the
>>> initial counter. So two threads can currently acquire that semaphore.
>>>
>>>> Condition variables IMO are unintuitive (eg the internal state 
>>>> change from
>>>> waiting on condition variable to waiting on mutex is completely 
>>>> invisible)
>>>> and hence very prone to logical bugs. I tend to avoid them where 
>>>> possible.
>>>
>>> If you have a producer-consumer-pattern condition variables are the most
>>> efficient way to handle this pattern.
>>>
>>
>> Really?
> 
> Yes. If the consumer and producer are constantly processing you usually
> have no kernel-calls.
> 

Huh? What about the contention that can cause slow paths to me hit that 
might get into a kernel wait on a sync object?

Put a convar-mutex based FIFO under heavy load vs a lock/wait-free one? 
What one is more efficient? Yes there are atomic FIFO's that have wait 
free fast paths.