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. Thanks, Mathieu -- Mathieu Desnoyers EfficiOS Inc. https://www.efficios.com
