On 2025-12-19 10:42, Joel Fernandes wrote:
IMHO the overflow case is "special" and should not happen often, otherwise things are "bad" anyway. I am not sure if this kind of complexity will be worth it unless we know HP forward-progress is a real problem. Also, since HP acquire will be short lived, are we that likely to not get past a temporary shortage of slots?
Given that we have context switch integration which moves the active per-cpu slots to the overflow list, I can see that even not-so-special users which get preempted or block regularly with active per-cpu slots could theoretically end up preventing HP scan progress. Providing HP scan progress guarantees is IMO an important aspect to consider if we want to ensure the implementation does not cause subtle HP scan stall when its amount of use will scale up.
Perhaps the forward-progress problem should be rephrased to the following?: If a reader hit an overflow slot, it should probably be able to get a non-overflow slot soon, even if hazard pointer slots are over-subscribed.
Those are two distinct forward progress guarantees, and I think both are important: * Forward progress of HP readers, * Forward progress of HP scan. Thanks, Mathieu -- Mathieu Desnoyers EfficiOS Inc. https://www.efficios.com
