Path: news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>
Newsgroups: comp.lang.c++
Subject: Re: Wait-free Hazard Pointers Using Std Atomics
Date: Tue, 3 Jun 2025 12:09:09 -0700
Organization: A noiseless patient Spider
Lines: 36
Message-ID: <101nh8m$768d$3@dont-email.me>
References: <1012o73$276nn$1@dont-email.me> <101830t$3faku$1@dont-email.me>
 <101aisl$2cjp$1@dont-email.me> <101idao$2erne$4@dont-email.me>
 <101l7aq$3hntf$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Tue, 03 Jun 2025 21:09:10 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="718ce13fa2b04f8a774c98602fe03811";
	logging-data="235789"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18s0X8wp8fYo3l4669CPGqsnPkGjgP+6nI="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:Lc+oN8FIJVhHye/65z5fzfXdm7A=
Content-Language: en-US
In-Reply-To: <101l7aq$3hntf$1@dont-email.me>

On 6/2/2025 3:07 PM, jseigh wrote:
> On 6/1/25 16:31, Chris M. Thomasson wrote:
>> On 5/29/2025 2:17 PM, jseigh wrote:>>>
>>>
>>> Push may wait-free but pop isn't event lock-free.
>>
> 
>>
>> Actually, I like my futex stack experiment as is. normal CAS for push, 
>> SWAP for pop. It needs to have multiple stacks and distribute across 
>> them because popping all from a single stack can mean a thread gets 
>> too much work. Push lock-free, pop wait-free.
>>
>>
> Well you actually have a lot of leeway in concurrent queue semantics.
> Drop the FIFO requirements since they're not really observable for
> all practical purposes and just concentrate on throughput forward
> progress.
> 
> And wait-free is highly overrated. It seems to be important only in
> theses, technical papers and obscure blogs, not so much is real world
> applications which is one reason I not going to implement it.

Perhaps. However, using a loop-free exchange is "faster" than a loop 
based CAS? On Intel, XCHG vs a CMPXCHG loop?


>>
>>>
>>> Anyway, after some consideration, I'm off on this
>>> wait-free hazard pointer.  The lock-free version is
>>> more than performant.
> 
> I did post on my blog how to improve reclaim forward progress for the
> wait-free hazard pointer so it's equivalent to a proxy collector.