[RFC] P2530R3 std::hazard_pointer prototype

[PaulXiCao]

Hi Tomasz,

Thanks for the feedback, both suggestions are addressed:

   - slots_ now uses std::deque<PaddedSlot> directly, dropping the
   unique_ptr indirection: gh commit
   <https://github.com/PaulXiCao/hazard_pointer_prototype/commit/9f1b85e871b53d574067d2bfdcd40e5d0d40a903>
   - acquire_slot() uses std::find on vector<bool>: gh commit
   <https://github.com/PaulXiCao/hazard_pointer_prototype/commit/e420eb1021250468f0a79d789fa54b0d65f2b201>
   - release_slot() updated to std::find_if for consistency: gh commit
   <https://github.com/PaulXiCao/hazard_pointer_prototype/commit/f36ed6150dd1f9d7fc6f2e1104647e73f3df26cb>

I'm also already working on a port to libstdc++. Any feedback on
implementation details (memory ordering, locking structure, thread-exit
handling) would be very welcome at this stage.

Regards,
Paul


On Thu, May 28, 2026 at 11:22 AM Tomasz Kaminski <tkaminsk@redhat.com>
wrote:

> 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/20260602/6cae812f/attachment-0001.htm>