[RFC] P2530R3 std::hazard_pointer prototype

[Tomasz Kaminski]

Hi Paul,

Unfortunately, due the upcoming C++ committee in meeting in Brno,
I do not think I will be able to provide a timely feedback.

On Tue, Jun 2, 2026 at 8:27 PM PaulXiCao <paulxicao7@gmail.com> wrote:

> 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.
>
This is also outside of area of expertise, so I will need to allocate a
decent amount of time for analysis.


>
> 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/20260603/a334505f/attachment.htm>