I do not understand how the implementation [1] and claimed performance make any sense.
In try_protect() (page 11) they only issue a load with acquire semantics (L-LS after load). The hazard pointer store, which is the actual guard, is not obviously ordered with respect to the post-acquire body using a S-LS. As such, the core, A, is allowed to reorder the store to the hazard pointer until after A has "acquired" and begun using the contained data which means any other core, X, attempting to reclaim that data can observe that the hazard pointer is NULL and thus can be reclaimed in that window even though the A has already determined that it is has "acquired" ownership and thus believes no other core can reclaim it.
I am not familiar with the shenanigans of modern C++ atomics, so maybe there is some implied ordering or atomics occurring in that code guaranteeing that the guarding store is atomically dependent on the load such that the acquire barrier is adequate? Otherwise that is just plain incorrect.
If it is incorrect, then they would require a S-LS barrier following the protecting store which is a full barrier on x86-64 and AArch64 which usually has performance more on the order of a uncontended atomic (~10-100 ns) rather than 1 ns. That lends further support for the concept that it is incorrect since the claimed performance is only possible if the hazard pointer was set with just a bare, unordered store with no atomics (even uncontended) anywhere in that code path.
In try_protect() (page 11) they only issue a load with acquire semantics (L-LS after load). The hazard pointer store, which is the actual guard, is not obviously ordered with respect to the post-acquire body using a S-LS. As such, the core, A, is allowed to reorder the store to the hazard pointer until after A has "acquired" and begun using the contained data which means any other core, X, attempting to reclaim that data can observe that the hazard pointer is NULL and thus can be reclaimed in that window even though the A has already determined that it is has "acquired" ownership and thus believes no other core can reclaim it.
I am not familiar with the shenanigans of modern C++ atomics, so maybe there is some implied ordering or atomics occurring in that code guaranteeing that the guarding store is atomically dependent on the load such that the acquire barrier is adequate? Otherwise that is just plain incorrect.
If it is incorrect, then they would require a S-LS barrier following the protecting store which is a full barrier on x86-64 and AArch64 which usually has performance more on the order of a uncontended atomic (~10-100 ns) rather than 1 ns. That lends further support for the concept that it is incorrect since the claimed performance is only possible if the hazard pointer was set with just a bare, unordered store with no atomics (even uncontended) anywhere in that code path.
[1] https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p25...