Sujet : Re: Wait-free Hazard Pointers Using Std Atomics
De : jseigh_es00 (at) *nospam* xemaps.com (jseigh)
Groupes : comp.lang.c++Date : 23. Jun 2025, 12:03:13
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <103bc9h$175qq$1@dont-email.me>
References : 1 2 3 4 5 6
User-Agent : Mozilla Thunderbird
On 6/3/25 15:09, Chris M. Thomasson wrote:
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.
I've been doing reader lock-free too long. I just realized how
trivially simple it is to do read write lock-free for almost any data
structure. That's slightly embarrassing.
Joe Seigh
Wait-free Hazard Pointers Using Std Atomics
Re: Wait-free Hazard Pointers Using Std Atomics