Path: ...!3.eu.feeder.erje.net!feeder.erje.net!news.in-chemnitz.de!news.swapon.de!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: Sat, 14 Sep 2024 12:12:50 -0700
Organization: A noiseless patient Spider
Lines: 33
Message-ID: <vc4n7i$1knu4$3@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>
 <vbvdib$c8gk$8@dont-email.me>
 <vc1b7l$s2bh$1@raubtier-asyl.eternal-september.org>
 <vc24no$10sij$5@dont-email.me>
 <vc2imj$13dck$2@raubtier-asyl.eternal-september.org>
 <vc3kdk$1d42p$1@dont-email.me>
 <vc3llr$1db7m$1@raubtier-asyl.eternal-september.org>
 <vc3q8h$1e9p8$1@dont-email.me>
 <vc3r7a$1eeqb$2@raubtier-asyl.eternal-september.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sat, 14 Sep 2024 21:12:50 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="3671068c93cccefc7b8d67f34ac1ec5f";
	logging-data="1728452"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/5YHqTuRShnuYoWaqNJSbBD8AlyLGY34A="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:/RbH/bS7R40+Q3gyKLewITXkqEI=
Content-Language: en-US
In-Reply-To: <vc3r7a$1eeqb$2@raubtier-asyl.eternal-september.org>
Bytes: 3042

On 9/14/2024 4:15 AM, Bonita Montero wrote:
> Am 14.09.2024 um 12:58 schrieb Muttley@dastardlyhq.com:
> 
>>>> Everything has to be polled at some level except hardware interrupt 
>>>> based
>>>> code.
> 
>>> If the queue is empty CPU-time is usually handed voluntary to
>>> another thread - not with a lock-free-queue.
> 
>> I think you missed the point - locks are just a kernel construct. 
>> Their state still has to be polled by the kernel.
> 
> No, their state is maintained in userspace and the kernel is only there
> for the slow path when there's contention.
> 
>> Unless the locking mechanism is implemented in hardware then software
>> has to manage it whether in user  space or kernel space.
> 
> The fast-path is implemented in hardware through the support of atomics.
> 
> But that wasn't the point in the discussion because this doesn't relate
> to lock free queue's drawback that there's no slow path and the queue
> has to be polled.
> 

You have to think outside the box for a moment... :^) There are 
interesting ways to turn lock/wait/obstruction-free algorithms into ones 
that can wait on conditions. This gives them lock/wait free fast paths. 
The slow paths (waiting in kernel, signalling/broadcasting) are only hit 
on certain conditions.

So if the queue is empty, a thread can choose to wait if it wants to.