On Tue, Oct 13, 2026 at 09:04:50AM -0400, Mathieu Desnoyers wrote:
> On 2026-10-13 08:48, Boqun Feng wrote:
> > On Tue, Oct 13, 2026 at 03:40:36PM +0800, Lai Jiangshan wrote:
> [...]
> > >
> > > This breaks the forward-progress argument used by the underlying
> > > hazptr implementation: after removing an object from publication,
> > > there should not be a continuing stream of new readers acquiring
> > > that same object. Here, the bucket is never unpublished.
> > >
> > > For example, let B be the bucket containing key K:
> > >
> > > Updater Reader Scan kthread
> > > ------- ------ ------------
> > > Unlink K from B
> > > hazptr_synchronize(B)
> > > Acquire B
> > > Observe B;
> > > retain waiter
> > > Release B
> > > Acquire B again
> > > Observe B;
> > > retain waiter
> > > Release B
> > > ... ...
> > >
> >
> > This is more of an implementation issue,
> I agree with Boqun about the point that this is really an implementation
> issue.
>
> If we care about forward progress in the scenario of a repeated
> address reuse, we just need to wire up a "0/1" low bit phase tag and
> make hazptr acquire pick it up and set it within its hazptr slot. This
> will ensure forward progress in that scenario. hazptr synchronzie
> would therefore flip this phase between 0 and 1, and check that the
> pointer it's looking for is not set in the other phase, in alternance,
> handling both phases within one synchronize. Indeed, this phase concept
> comes from the realm of RCU implementations.
>
> I think that the overall mindset so far has been "RCU does this" and
> "Hazard pointers do this" as if those were entirely predefined
> mechanisms. I think the way forward is not "one or the other", but
> rather to combine the strengths of each of those mechanisms into
> something better.
There have been a number of academic attempts to do just that, all of
which ended up providing the worst of both worlds. Large memory footprint
*and* conditional pointer traversal being the usual suboptimal outcome. :-(
However, I don't see a problem with use of hazard pointers for static
addresses, at least assuming use of something like the above low-bit
trick to ensure forward progress.
Thanx, Paul
> Thanks,
>
> Mathieu
>
> --
> Mathieu Desnoyers
> EfficiOS Inc.
> https://www.efficios.com
