On Tue, Oct 13, 2026 at 9:04 PM Mathieu Desnoyers <[email protected]> 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.
Regardless of which implementation approach is adopted, this would effectively introduce a new read-side synchronization mechanism based on hazard pointers. I would prefer to see it introduced under a distinct name in the kernel, so that its semantics and intended usage can be clearly distinguished from those of conventional hazard pointers. Thanks, Lai > > 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. > > Thanks, > > Mathieu > > -- > Mathieu Desnoyers > EfficiOS Inc. > https://www.efficios.com
