[RFC] P2530R3 std::hazard_pointer prototype

[Tomasz Kaminski]

Hi,

Not a full review, but have you considered using a deque for slots.
The container seems to only grow, and this will guarantee the address.
stability. It seems that hive, once implemented, may also be a good option.
candidate to use, as it allows erasure while preserving pointer stability.

Also, when iterating a vector<bool> in search on inactive slot, I would
suggest using std::find. There is a change that we may optimize this
algorithm for seraching/counting inside bit containers.

Regards,
Tomasz

On Mon, May 25, 2026 at 8:58 PM PaulXiCao <paulxicao7@gmail.com> wrote:

> Hi all,
>
> I have a prototype implementation of the C++26 <hazard_pointer>
> facility (P2530R3) and would like feedback before porting it into
> libstdc++ style.
>
>   https://github.com/PaulXiCao/hazard_pointer_prototype
>
> Single-header, namespace proto, full API surface
> (hazard_pointer_obj_base, hazard_pointer, make_hazard_pointer). Builds
> and tests pass under gcc-14/16, clang-21, MSVC; TSan and ASan clean.
> README.md covers memory ordering rationale and the synchronize()
> collect-then-snapshot ordering; PORTING_NOTES.md lists the
> transformations still needed for libstdc++ (e.g. uglification,
> _GLIBCXX_ macros, fine-grained <bits/...> includes, __gthread
> primitives).
>
> Any feedback welcome before I start the libstdc++ rewrite -- in
> particular on the memory ordering choices, the synchronize() design,
> and API surface conformance to P2530R3, but I am also interested in
> anything else that catches your eye.
>
> One open issue worth flagging: gcc -fcontracts ICEs on a defaulted
> default constructor with a post() annotation. Filed as PR125403; the
> prototype carries a small workaround.
>
> Thanks,
> Paul
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://gcc.gnu.org/pipermail/libstdc++/attachments/20260528/e459d4a0/attachment.htm>