CppCon 2024 学习:Interesting Upcoming Features from Low Latency, Parallelism and Concurrency

一、背景：为什么需要 Atomic Min / Max（P0493）

1⃣ 问题本质

在多线程程序中，经常会出现这样的需求：

多个线程并发地更新一个共享变量，用来记录最小值 / 最大值
数学上可以抽象为：
x ← min ⁡ ( x , v i ) 或 x ← max ⁡ ( x , v i ) x \leftarrow \min(x, v_i) \quad \text{或} \quad x \leftarrow \max(x, v_i)x←min(x,vi​)或x←max(x,vi​)
其中：

• x xx是共享原子变量
• v i v_ivi​是线程i ii提供的候选值

2⃣ 没有原子操作会发生什么？

如果用普通变量或非原子更新：

if(v<x)x=v;

在并发下会出现：

• 读-改-写非原子
• 线程交错导致丢更新（lost update）
• 数据不一致、不可预测行为（UB）

3⃣ 为什么“加锁”不够好？

虽然mutex能解决正确性问题，但：

• 高争用时性能差
• 阻塞 → 上下文切换
• 难以构建lock-free/wait-free结构

4⃣ Atomic Min / Max 的核心价值

把 “比较 + 更新” 合并成一个原子操作
保证：
update ( x ) ; 是线性化的 \text{update}(x) ;\text{是线性化的}update(x);是线性化的
从而实现：

• 无锁并发更新
• 数据完整性
• 高并发可扩展性

二、典型应用场景

Atomic min / max 在以下领域非常常见：

Lock-free 数据结构

• 并发优先级队列
• 最小时间戳 / 最大序号维护

并行归约（Parallel Reduction）

• OpenMP / TBB / GPU-style reduction
• 例如：并行计算最小误差、最大评分

优化算法

• 全局最优解（best-so-far）
• 分支限界（branch & bound）

统计信息收集

• 延迟最大值
• 最小响应时间
• 峰值资源占用

三、C++26 提议接口（标准层面）

1⃣ 非成员函数形式

namespacestd{template<classT>Tatomic_fetch_max(atomic<T>*obj,typenameatomic<T>::value_type arg)noexcept;template<classT>Tatomic_fetch_max_explicit(atomic<T>*obj,typenameatomic<T>::value_type arg,memory_order order)noexcept;// 同样提供 atomic_fetch_min / _explicit}

2⃣ 返回值语义（非常重要）

与atomic_fetch_add一致：

返回的是“更新前的旧值”
形式化表达：
old = x before \text{old} = x_{\text{before}}old=xbefore​
并执行：
x ← max ⁡ ( x , arg ) x \leftarrow \max(x, \text{arg})x←max(x,arg)

3⃣ 成员函数版本（atomic）

标准还会提供：

std::atomic<T>a;autoold=a.fetch_max(v);autoold=a.fetch_max(v,std::memory_order_relaxed);

四、内存序（memory_order）语义

默认版本

atomic_fetch_max(&a,v);

等价于：

atomic_fetch_max_explicit(&a,v,std::memory_order_seq_cst);

显式版本的使用原则

• 统计 / reduction
  →memory_order_relaxed
• 同步 / 发布语义
  →release/acquire
  数学上可以理解为：
  atomicity ; ≠ ; ordering \text{atomicity} ;\neq; \text{ordering}atomicity;=;ordering
  Atomic min/max 只保证原子性，内存顺序仍需你自己选。

五、实现方式：标准并不强制怎么实现

C++26 只规定语义，实现依赖平台。

六、实现方式一：CAS Loop（Compare-And-Swap）

1⃣ 基本 CAS 实现

T old=a.load();while(old<v&&!a.compare_exchange_weak(old,v)){// old 被更新为当前值}returnold;

数学模型

loop until { x ≥ v or CAS succeeds \text{loop until } \begin{cases} x \ge v \\ \text{or CAS succeeds} \end{cases}loop until{x≥vor CAS succeeds​

2⃣ 问题

• 高争用时：
  • 自旋严重
  • cache line ping-pong
• 性能随线程数恶化

七、实现方式二：Optimized CAS

优化点包括：

• 先load判断是否需要 CAS
• 减少不必要的 CAS 尝试
• 使用compare_exchange_weak+ backoff
  这种实现：
• 在低~中等争用下性能可接受
• 在无硬件指令的平台上是主力方案

八、实现方式三：硬件直接支持（最快）

1⃣ Direct Instruction

部分架构提供类似指令：

• x86：LOCK CMPXCHG组合优化
• GPU：原生 atomic min/max
• RISC-V / ARM：特定原子扩展
  效果：
• 单条或少量指令
• 极低延迟
• 极高吞吐

2⃣ LL/SC（Load-Link / Store-Conditional）

在 ARM / PowerPC 上：

LL r0, [x] cmp r0, v SC r1, v, [x]

若中途被打断，SC失败自动重试。

九、性能对比总结

十、为什么 C++26 才加？

原因总结：

1. 各架构支持不统一（早期）
2. API 设计需要与 memory_order 对齐
3. 避免滥用 / 误用
4. 与 GPU / 并行算法需求成熟度有关

十一、一句话总结（工程视角）

Atomic min/max 把“并发归约”的核心原语，正式提升为标准一等公民。
公式化总结：
atomic_fetch_max = atomic ( max ⁡ ) \text{atomic\_fetch\_max} = \text{atomic}( \max )atomic_fetch_max=atomic(max)
它不是语法糖，而是：

• lock-free 结构的地基
• 并行算法的标配
• 高性能统计与优化的关键原语

一、这篇论文到底在解决什么问题？（一句话版）

把“并发条件更新（conditional write）”这个长期存在、硬件早已支持的原语，正式引入 C++<atomic>标准库。
用公式表示就是，把下面这个并发模式：
x ← max ⁡ ( x , v ) 或 x ← min ⁡ ( x , v ) x \leftarrow \max(x, v) \quad\text{或}\quad x \leftarrow \min(x, v)x←max(x,v)或x←min(x,v)
升级为标准原子读-改-写操作（RMW）。

二、历史背景：为什么不是新东西，却拖了这么久？

1⃣ 原子加法比原子 max/min 还“年轻”

• fetch_add：1982（NYU Ultracomputer）
• fetch_max / fetch_min：1988 年前后就已经出现
  比很多人想象的要早
  但问题是：
• 各架构语义不一致
• C++ 内存模型成熟得比较晚
• conditional write 在标准里一直是“灰色地带”

2⃣ 为什么应用层强烈需要？

论文列的动机，本质可以归为四类：

Lock-free 数据结构

• 无锁队列
• 序号 / 时间戳推进

并行归约（reduction）

• OpenMP 的reduction(max: ...)
• 数据并行统计

优化 / 搜索算法

• global best-so-far
• branch & bound 剪枝

统计信息

• 最大延迟
• 峰值内存
• 最大输入规模
  这些场景的共同点是：

写入发生不频繁，但读取和比较非常频繁

三、核心难点：conditional write 的语义之争

这是整篇论文最关键、也最有争议的部分。

1⃣ 什么是 conditional write？

伪代码：

if(new>old)old=new;

在并发里，这可以有两种实现语义：

2⃣ 方案 A：read-modify-write（RMW）

无论值是否改变，都算一次“写”
x ← max ⁡ ( x , v ) x \leftarrow \max(x, v)x←max(x,v)
特点：

• 和fetch_add完全一致
• 每个参与线程都要抢 cache line
• 高争用下性能差

3⃣ 方案 B：read-and-conditional-store（RCS）

只有真的变大 / 变小，才写
if v > x then x ← v \text{if } v > x \text{ then } x \leftarrow vifv>xthenx←v
特点：

• 写入次数显著减少
• 硬件（ARM / RISC-V / POWER）天然支持
• 性能非常好
  但问题是：

这不是严格意义上的 RMW

4⃣ 标准委员会的最终结论（R3 → R5）

语义上：规定为 RMW
实现上：允许用 RCS + 修补
也就是：

行为像 RMW，但实现可以“偷懒”

四、三种 CAS-loop 实现对比（5.1 / 5.2 / 5.3）

这是论文里工程含量最高的部分。

5.1 非 conforming（不符合标准）的实现

while(max(v,t)!=t){if(pv->compare_exchange_weak(t,v))break;}

特点：

• 如果值没变 → 完全不写
• 不满足 RMW 语义
• 被标准否掉

5.2 纯 RMW 实现（最“老实”的）

while(!pv->compare_exchange_weak(t,max(v,t)));

特点：

• 每轮都会写
• cache line 抢占严重
• 高争用下性能灾难

5.3“聪明”的折中实现（最终推荐）

autot=(mr!=m)?pv->fetch_add(0,m):pv->load(mr);while(max(v,t)!=t){if(pv->compare_exchange_weak(t,v,m,mr))returnt;}returnt;

这个实现的关键思想：

• 只有当 memory_order 要求 release 时，才强制一次写
• 否则：
  • 允许只读不写
• 用fetch_add(0)人为制造一次“可观察的写”

为什么这是合法的吗？

因为：
额外一次 dummy 写 ; ⇏ ; 可观测语义变化 \text{额外一次 dummy 写} ;\not\Rightarrow; \text{可观测语义变化}额外一次dummy写;⇒;可观测语义变化
在 C++ 内存模型下，这是不可区分的行为。

五、为什么没有 infix operator？

现状：

• +=→ 有
• &=→ 有
• max=→ 不存在

能不能提供“返回新值”的接口？

比如：

autonew=a.fetch_max_new(v);

论文结论是：不值得
原因：

• max/min是不可逆操作
• 新值可以用：
  max ⁡ ( old , v ) \max(\text{old}, v)max(old,v)
  即：

autoold=a.fetch_max(v);autonewv=std::max(old,v);

所以最终只保留fetch_xxx（返回旧值）

六、指针语义：为什么这么“严格”？

标准规定：

fetch_max/fetch_min对指针的比较
等价于使用std::max / std::min
也就是说：

• 只能比较：
  • 指向同一个 complete object
  • 或同一数组内的指针
    否则：

<不形成 strict weak ordering
→行为未定义

为什么不像其他 atomic 那样“兜底”？

原因是：

• fetch_add可能产生“新值”
• fetch_max只会返回：
  • 旧值
  • 或调用者提供的值
    不“创造”新指针
    所以不提供 escape clause

工程建议（论文暗示）

如果你真的需要：

atomic<T*>a;

跨对象比较：
自己转成uintptr_t

七、为什么浮点被移除了？

这是 R5 的重要变化。

根本原因：浮点的 max/min 不是良序

问题点：

• NaN
• +0 / -0
• IEEE 754 特殊规则
  例如：
  max ⁡ ( NaN , x ) ≠ x \max(\text{NaN}, x) \neq xmax(NaN,x)=x

结论

• std::min / std::max本身就对浮点特殊处理
• 原子语义会更复杂
• 已有P3008专门处理：
  本提案专注整数 & 指针

八、Benchmark：为什么硬件支持这么重要？

测试平台

• ARM Graviton3（64 核）
• 对比：
  • CAS-loop（smart）
  • 硬件指令ldsmax

结果趋势（简化版）

硬件原生 min/max 是数量级优势

九、标准改动总结 ）

新增内容包括：

• 非成员函数：

  atomic_fetch_max atomic_fetch_min

• 成员函数：

  atomic<T>::fetch_max atomic<T>::fetch_min

• atomic_ref支持
• 整数 & 指针特化
• feature test macro：

  __cpp_lib_atomic_min_max

十、整篇论文的“真正价值”（总结）

P0493 不是“加几个 API”，
而是把“条件更新”正式纳入 C++ 原子语义体系。
公式化总结：
conditional write ; ⟶ ; standard RMW primitive \text{conditional write} ;\longrightarrow; \text{standard RMW primitive}conditional write;⟶;standard RMW primitive

你可以把它理解为：

• lock-free 算法的“最后一块基础砖”
• 并行 reduction 的原生支持
• 为 GPU / heterogeneous 并发铺路

一、示例代码在“并发层面”到底做了什么？

#include<atomic>#include<thread>#include<vector>std::atomic<int>max_value{0};

①std::atomic<int> max_value{0};

• 这是一个原子共享变量
• 所有线程都会：
  • 并发读取它
  • 并发尝试更新它
• 不需要互斥锁（mutex）

voidfind_max_in_range(intstart,intend){for(inti=start;i<end;++i){max_value.fetch_max(i,std::memory_order_relaxed);}}

②fetch_max的语义（核心）

这一句在语义上等价于：
old ← max_value max_value ← max ⁡ ( old , i ) \text{old} \leftarrow \text{max\_value} \ \text{max\_value} \leftarrow \max(\text{old}, i)old←max_valuemax_value←max(old,i)
但整个过程是原子的（不可被打断）。

③ 多线程下会发生什么？

假设两个线程并发执行：

• 线程 A：fetch_max(137)
• 线程 B：fetch_max(245)
  最终结果满足：
  max_value = max ⁡ ( … , 137 , 245 ) \text{max\_value} = \max(\dots, 137, 245)max_value=max(…,137,245)
  顺序不确定，但结果确定。

intmain(){std::vector<std::thread>threads;for(inti=0;i<10;++i){threads.emplace_back(find_max_in_range,i*100,(i+1)*100);}

④ 线程划分方式

• 共 10 个线程
• 每个线程处理一个区间：
  [ 0 , 100 ) , [ 100 , 200 ) , … , [ 900 , 1000 ) [0,100), [100,200), \dots, [900,1000)[0,100),[100,200),…,[900,1000)
  这保证了：
• 所有i都会被尝试写入
• 理论最大值应为：
  max ⁡ = 999 \max = 999max=999

for(auto&thread:threads){thread.join();}

⑤join()的并发语义（非常重要）

• join()不是原子操作
• 但它提供了一个线程完成的 happens-before 保证
  即：
  线程内的所有操作 ; ; happens-before ; ; join() 返回 \text{线程内的所有操作} ;;\text{happens-before};; \text{join() 返回}线程内的所有操作;;happens-before;;join()返回

std::cout<<"Maximum value: "<<max_value<<std::endl;

⑥ 为什么这里读max_value是安全的？

因为：

• 所有线程已经join()
• 不再有并发写入
• 即使fetch_max用的是memory_order_relaxed
  join 提供了同步，而不是 atomic 本身

二、为什么memory_order_relaxed在这里是完全正确的？

这是这段代码最容易被误解的地方。

1⃣ 我们真正关心的是什么？

我们关心的是：
max_value 最终等于所有 i 的最大值 \text{max\_value 最终等于所有 i 的最大值}max_value最终等于所有i的最大值
我们不关心：

• 每一次fetch_max的先后顺序
• 某个线程“看到”另一个线程的中间状态

2⃣relaxed保证了什么？

std::memory_order_relaxed

保证两件事：

1. 原子性（atomicity）
2. 修改是不可撕裂的（no tearing）
   但不保证：

• 顺序
• 可见性传播时机
• 与其他内存的关系

3⃣ 为什么这已经足够？

因为这里的计算是一个幂等归约（idempotent reduction）：
max ⁡ ( max ⁡ ( a , b ) , c ) = max ⁡ ( a , max ⁡ ( b , c ) ) \max(\max(a,b),c) = \max(a,\max(b,c))max(max(a,b),c)=max(a,max(b,c))
也就是说：

• 顺序完全不重要
• 不需要 happens-before
• 不需要跨变量同步
  这是relaxed 的经典使用场景

三、Memory Ordering 强弱层级（从弱到强）

你列出的层级可以用一条“语义单调增强链”表示：
relaxed ⊂ acquire / release ⊂ acq_rel ⊂ seq_cst \text{relaxed} \subset \text{acquire / release} \subset \text{acq\_rel} \subset \text{seq\_cst}relaxed⊂acquire / release⊂acq_rel⊂seq_cst

1⃣memory_order_relaxed

fetch_max(v,relaxed)

• 原子性
• ✘ 不同步其他内存
• ✘ 不建立 happens-before
  适合：
• 计数器
• max/min
• 统计
• 并行 reduction

2⃣memory_order_release

fetch_max(v,release)

语义：

在这次原子操作之前的所有写入
对随后 acquire 读取它的线程可见
数学化表示：
writes before → release atomic \text{writes}_\text{before} \xrightarrow{\text{release}} \text{atomic}writesbefore​release​atomic

3⃣memory_order_acquire

load(acquire)

语义：

看到这个原子值
⇒ 一定能看到对应的 release 写入
atomic → acquire reads after \text{atomic} \xrightarrow{\text{acquire}} \text{reads}_\text{after}atomicacquire​readsafter​

4⃣memory_order_acq_rel

fetch_max(v,acq_rel)

• 对写：release
• 对读：acquire
  用于：
• 状态推进
• 阶段切换
• lock-free 协议

5⃣memory_order_seq_cst（最强）

fetch_max(v,seq_cst)

保证：

• 所有seq_cst原子操作
• 存在一个全局总序
  ∃ single total order \exists\text{single total order}∃single total order
  性能代价最高

四、什么时候不能用relaxed？

考虑这种情况：

structData{intpayload;};Data data;std::atomic<int>max_version;

线程 A：

data.payload=42;max_version.fetch_max(1,std::memory_order_release);

线程 B：

if(max_version.load(std::memory_order_acquire)>=1){// 希望看到 payload == 42}

这里：

• 必须release + acquire
• 否则 B 可能看到：
  • max_version == 1
  • 但payload仍是旧值

五、为什么fetch_max特别适合 relaxed？

从数学角度看：
max ⁡ : ( T , T ) → T \max: (T, T) \to Tmax:(T,T)→T
满足：

• 交换律
• 结合律
• 幂等性
  这意味着：

只要保证单次操作原子，
整体结果天然正确
这正是 relaxed 的理想适用场景。

六、把这段代码用一句“专家级描述”总结

这是一个无锁、无同步依赖、基于幂等归约的并行最大值计算，
使用atomic::fetch_max+memory_order_relaxed，
正确性由原子性 + join 同步共同保证。

一、Current Status：提案目前处在什么阶段？

1⃣ 提案历史与状态

• 最早提出时间：2016 年
• 目标标准：C++26
• 当前版本：P0493R5（2024 年 2 月）
• 实现经验：
  • 已在Clang中进行过实验性实现
  • 表明该设计可实现、可优化、可落地

这类信息在 WG21 语境中意味着：
“该提案已经过多年打磨，进入收敛阶段”

2⃣ 为什么拖了这么久？

关键原因不是整数，而是：

浮点原子 min/max 的语义争议
整数版本：

• 语义清晰
• 与数学min ⁡ / max ⁡ \min / \maxmin/max一致
• 无 NaN、无符号零问题
  浮点版本：
• 涉及 IEEE-754 的角落语义
• 标准库内部历史包袱极重

二、Open Questions：委员会仍在讨论什么？

1⃣ 是否支持浮点类型？

问题本质：
是否存在一个“足够一致、可移植”的浮点 min/max 语义？ \text{是否存在一个“足够一致、可移植”的浮点 min/max 语义？}是否存在一个“足够一致、可移植”的浮点min/max语义？

• GPU / ARM：已经有硬件支持
• x86：支持在增长
• 标准库：语义仍未完全统一

2⃣ 是否提供“返回新值”的变体？

当前提案接口是：

Tatomic_fetch_max(atomic<T>*,T);

语义：
return old_value \text{return old\_value}return old_value
开放问题：

• 是否也应该支持：

Tatomic_fetch_max_new(...);

即：
return new_value = max ⁡ ( o l d , i n p u t ) \text{return new\_value} = \max(old, input)return new_value=max(old,input)
委员会通常更保守：

• 增加 API 意味着 ABI / 教学成本
• 可通过一次 load + fetch 实现

三、结论性判断（整数版本）

Atomic min/max operations are valuable additions
原因总结为三点：

1. 正确性
   • 消除数据竞争
   • 明确原子语义
2. 性能
   • 避免 mutex
   • 利用硬件原子指令
3. 适用性
   • 高并发
   • 高扩展性
     适用场景包括：

• Lock-free 数据结构
• 并行归约（OpenMP / TBB）
• 优化算法
• 统计与监控

四、Atomic Floating-Point Min/Max（P3008）

这是当前最难、也是最有争议的部分。

1⃣ 为什么浮点比整数难？

浮点存在三个“非直觉点”：

(1) NaN（Not a Number）

• NaN不满足自反性：
  NaN ≠ NaN \text{NaN} \neq \text{NaN}NaN=NaN
• 比较结果不稳定：
  NaN < x , ; NaN > x , ; NaN = = x ; 均为 false \text{NaN} < x,; \text{NaN} > x,; \text{NaN} == x ;\text{均为 false}NaN<x,;NaN>x,;NaN==x;均为false

(2) 有符号零（+0 与 −0）

− 0.0 = = + 0.0 但符号位不同 -0.0 == +0.0 \quad \text{但符号位不同}−0.0==+0.0但符号位不同
比较关系并非完全直觉。

(3) IEEE-754 历史差异

不同平台、不同指令，对：

• NaN
• signed zero
  处理方式不同。

2⃣ C++ 中已有的“混乱历史”

(a)std::min / std::max

std::min(NaN,2.0f);// Undefined Behavior

• 标准明确：UB
• 这是为了性能 + 简化语义

(b) C 函数族：fmin / fmax

• 将 NaN 视为missing data
• 返回“非 NaN 的值”
• signed zero 行为依实现

© C23 新引入的一组函数

3⃣ 硬件现状（非常关键）

GPU / ARM 的事实：

• GPU：
  • 原生支持 atomic float min/max
  • NaN 直接忽略
• ARM v8.1+：
  • 提供原子浮点最值指令
  • 语义接近fminimum_num
    即硬件已经在用一种“事实标准”。

五、P3008 的设计取向

1⃣ 提议的浮点原子接口

floatfetch_min(float,memory_order=seq_cst)noexcept;floatfetch_max(float,memory_order=seq_cst)noexcept;

语义约束：

• NaN：行为未指定（unspecified）
• signed zero：推荐− 0 < + 0 -0 < +0−0<+0（但非强制）

这里用的是unspecified，而不是 UB
是一次重大改进

2⃣ 明确语义版本（更安全）

基于 C23：

floatfetch_fminimum(...);floatfetch_fmaximum(...);floatfetch_fminimum_num(...);floatfetch_fmaximum_num(...);

语义对应关系：

• fminimum / fmaximum
  • NaN = 错误
• fminimum_num / fmaximum_num
  • NaN = 缺失数据
    数学上：
    fminimum_num ( x , NaN ) = x \text{fminimum\_num}(x, \text{NaN}) = xfminimum_num(x,NaN)=x

六、为什么委员会现在“敢”推进浮点版本？

原因有三：

1. 硬件已经在用
   • GPU / ARM 已落地
2. C23 已统一语义
   • C 与 C++ 再次对齐
3. 经验教训足够多
   • std::min/max的 UB 被认为是失败设计

七、最终总结（专家视角）

Atomic min/max（整数）已经是“无争议必需品”。
浮点版本不再追求完美，而是追求“可实现、可解释、可移植”。
核心思想转变：
从“数学完美” → “工程可用” \text{从“数学完美”} \rightarrow \text{“工程可用”}从“数学完美”→“工程可用”

一、核心结论（先给答案）

在高并发（高线程数）场景下：

Native atomic min/max ≫ CAS loop 实现 \text{Native atomic min/max} \gg \text{CAS loop 实现}Native atomic min/max≫CAS loop实现

性能差距会随着并发度上升而指数式放大。
原因不是“实现技巧”，而是硬件一致性协议与冲突模型的根本不同。

二、CAS loop：为什么会在高并发下性能崩塌？

1⃣ CAS loop 的基本结构

一个典型的fetch_maxCAS 实现：

T old=atomic.load(relaxed);while(old<value&&!atomic.compare_exchange_weak(old,value,relaxed,relaxed)){// old 被更新为当前值，继续重试}returnold;

逻辑抽象为：
repeat until success: { read x try write max ⁡ ( x , v ) \text{repeat until success:} \begin{cases} \text{read } x \\ \text{try write } \max(x, v) \end{cases}repeat until success:{readxtry writemax(x,v)​

2⃣ 高并发下的本质问题：冲突概率

设：

• N NN= 并发线程数
• 所有线程都在更新同一个 cache line
  那么在任意时间点：
  P ( CAS success ) ≈ 1 N P(\text{CAS success}) \approx \frac{1}{N}P(CAS success)≈N1​
  即：
• 一个线程成功
• N − 1 N-1N−1个线程失败、回退、重试

3⃣ CAS loop 的性能退化链条（对应图左侧）

(1) Higher Thread Count

⬇

(2) Increased Contention

• 同一 cache line
• MESI 协议频繁失效
• cache line 在核之间“抖动”

(3) Increased Contention

⬇

(4) CAS Performance Degradation

退化体现在：

• 重试次数↑ \uparrow↑
• cache miss↑ \uparrow↑
• pipeline flush↑ \uparrow↑
• 内存序列化↑ \uparrow↑
  可以抽象为：
  Latency ∗ C A S ≈ O ( N ⋅ T ∗ c o h e r e n c e ) \text{Latency}*{CAS} \approx O(N \cdot T*{coherence})Latency∗CAS≈O(N⋅T∗coherence)

三、Native atomic min/max：为什么硬件支持能“救命”？

1⃣ 硬件原子 ≠ CAS 循环

关键区别：

CAS loop 是
“读 → 比较 → 写（可能失败）”

原生原子指令是
“比较 + 写 = 一个不可分割的硬件事务”

2⃣ 硬件实现方式（取决于架构）

常见路径包括：

• 单指令原子（GPU、ARM）
• LL/SC（Load-Link / Store-Conditional）
• 内部 microcode（x86 扩展）
  统一特性：
• 不会在失败后反复读 cache
• 失败路径极短
• 减少 coherence 往返

3⃣ 抽象性能模型

对原生 atomic min/max：
Latency n a t i v e ≈ O ( 1 ) \text{Latency}_{native} \approx O(1)Latencynative​≈O(1)
对 CAS loop：
Latency C A S ≈ O ( contention ) \text{Latency}_{CAS} \approx O(\text{contention})LatencyCAS​≈O(contention)
当线程数N → ∞ N \to \inftyN→∞：
Latency ∗ C A S Latency ∗ n a t i v e → ∞ \frac{\text{Latency}*{CAS}}{\text{Latency}*{native}} \to \inftyLatency∗nativeLatency∗CAS​→∞

四、SVG 图的逐层语义解读

下面我用“图 → 含义”的方式解释你 SVG 中的每一块。

第一层（Top Level）

Higher Thread Count

• 并行规模增大
• GPU / many-core CPU 的常态

Modern GPUs

• 数千线程
• 几乎必然高冲突

Atomic Float Min/Max Operations

• 抽象 API
• 可映射到：
  • 原生指令
  • 或 CAS fallback

Some newer CPUs

• ARM v8.1+
• 正在补齐硬件支持

Traditional Approach

• 历史实现
• 完全依赖 CAS loop

第二层（Second Level）

Increased Contention

• cache line 被频繁 invalidation
• 写者竞争

Native Hardware Support

• 原子在硬件层完成
• 不暴露中间状态

CAS Loop Implementation

• compare_exchange 重试
• coherence 风暴中心

第三层（Third Level）

CAS Performance Degradation

• 延迟急剧上升
• 吞吐下降

High Performance

• GPU / 原生 atomic
• 延迟稳定

Lower Performance

• CAS fallback
• 并发度越高越糟

五、为什么这对浮点 atomic min/max特别重要？

因为：

1. 浮点 min/max 常见于归约
   • 图像处理
   • 物理模拟
   • 机器学习
2. 归约 = 高并发 + 高冲突
3. GPU 已证明：没有原生原子就不可用
   这也是 P3008 强调：

“Hardware reality must inform standard design.”

六、一个形式化总结（可以直接放在 slide 里）

对共享变量x xx，并发执行：
x ← min ⁡ ( x , v i ) x \leftarrow \min(x, v_i)x←min(x,vi​)

• CAS 实现：
  cost ∼ O ( N ) \text{cost} \sim O(N)cost∼O(N)
• 原生原子：
  cost ∼ O ( 1 ) \text{cost} \sim O(1)cost∼O(1)

当N NN很大时，
只有原生 atomic min/max 具有可扩展性。

七、工程实践建议（非常重要）

如果平台支持原生 atomic min/max

• 一定要用
• 即使语义稍微宽松（如 NaN）

如果只能 CAS fallback

• 尽量：
  • 分片（sharding）
  • 局部归约 + 最终合并
  • 降低冲突频率

最终一句话总结

Atomic min/max 的标准化价值，不在“语法”，而在“性能可扩展性”。
没有原生支持，高并发下的 CAS 方案迟早会成为瓶颈。

一、代码整体在表达什么？

这段代码想说明的是：

如果 C++ 提供原生的 atomic floating-pointfetch_min / fetch_max，
那么它们的使用方式、返回值语义、并发行为，将与整数版本保持一致。
也就是：

• 返回旧值
• 原子地更新为 min/max
• 无需 CAS loop

二、逐行详细解析

#include<atomic>#include<cmath>#include<iostream>

• <atomic>：提供std::atomic<T>
• <cmath>：在真实实现中，浮点 min/max 语义通常与
  fmin / fmax / fminimum_num等相关
• <iostream>：演示输出

std::atomic<float>atomic_value(10.0f);

含义

• 创建一个原子浮点变量
• 初始值为10.0f
  在抽象内存模型中：
  a t o m i c v a l u e = 10.0 atomic_value = 10.0atomicv​alue=10.0

重要背景
在C++23 / C++26 之前：
std::atomic<float>存在
但没有fetch_min / fetch_max成员函数

这里的代码是基于 P3008（Atomic FP min/max）提案语义的示例

第一段：fetch_max

floatnew_max=15.0f;floatresult_max=atomic_value.fetch_max(new_max);

语义（按提案）

fetch_max(x)的抽象语义是：
old = a t o m i c _ v a l u e a t o m i c _ v a l u e = max ⁡ ( old , x ) return old \text{old} = atomic\_value \\ atomic\_value = \max(\text{old}, x) \\ \text{return old}old=atomic_valueatomic_value=max(old,x)return old
代入当前数值：
max ⁡ ( 10.0 , 15.0 ) = 15.0 \max(10.0, 15.0) = 15.0max(10.0,15.0)=15.0
所以：

• result_max == 10.0
• atomic_value == 15.0

std::cout<<"Old max: "<<result_max<<", New max: "<<atomic_value<<std::endl;

输出解释

Old max: 10, New max: 15

完全符合fetch-then-modify的 RMW 语义
与整数fetch_add / fetch_max行为一致

第二段：fetch_min

floatnew_min=5.0f;floatresult_min=atomic_value.fetch_min(new_min);

此时原子变量的值是：
a t o m i c v a l u e = 15.0 atomic_value = 15.0atomicv​alue=15.0
计算：
min ⁡ ( 15.0 , 5.0 ) = 5.0 \min(15.0, 5.0) = 5.0min(15.0,5.0)=5.0
但注意：示例输出中并没有发生更新
这是因为示例假设的语义是：

“min/max 只在更小/更大时才写入”
而给出的Expected output是：

Old min: 15, New min: 15

说明此示例的隐含语义是：
a t o m i c _ v a l u e = min ⁡ ( 15.0 , 5.0 ) = 15.0 atomic\_value = \min(15.0, 5.0) = 15.0atomic_value=min(15.0,5.0)=15.0
也就是说：

这里的fetch_min并不是std::min意义上的 min，
而是“更新为更小者（如果更小）”的conditional update。
这正是P3008 / 硬件 atomic min/max 的真实语义：
“如果新值不会改变结果，可以不写”

三、为什么第二次没有更新？（关键点）

抽象规则（P3008 推荐）

设旧值为x xx，新值为v vv：
f e t c h _ m i n ( v ) : { x ← v if v < x x ← x otherwise fetch\_min(v): \begin{cases} x \leftarrow v & \text{if } v < x \\ x \leftarrow x & \text{otherwise} \end{cases}fetch_min(v):{x←vx←x​ifv<xotherwise​
当前：
v = 5 , x = 15 v = 5, x = 15v=5,x=15
但示例输出却保持为15，说明这是在演示：

一种硬件友好的“min-so-far”语义
而不是数学意义上的：
x = min ⁡ ( x , v ) x = \min(x, v)x=min(x,v)

四、这正是浮点 atomic 的“敏感点”

1⃣ NaN 问题

如果：

floatv=NaN;

那么：

• std::min(x, NaN)→未定义
• fmin(x, NaN)→ 返回x
• 硬件 atomic →通常把 NaN 当“缺失值”
  所以 P3008 明确指出：

NaN 行为是“未指定”或“硬件一致即可”

2⃣ Signed Zero 问题

浮点中：
− 0.0 ≠ + 0.0 -0.0 \neq +0.0−0.0=+0.0
但：

• -0 < +0是否成立？
• 硬件大多认为成立
• 标准只“推荐”，不强制

五、并发角度：为什么 fetch_min/max 很重要？

在多线程中，你实际是在做：
x = min ⁡ ( x , v 1 , v 2 , … , v n ) x = \min(x, v_1, v_2, \dots, v_n)x=min(x,v1​,v2​,…,vn​)
这类模式出现在：

• 并行归约（reduction）
• GPU kernel
• 统计最大误差 / 最小能量
• 机器学习 loss tracking

如果没有原生 atomic

只能：

do{old=load();new=min(old,v);}while(!CAS(old,new));

其成本为：
O ( contention ) O(\text{contention})O(contention)

如果有原生 atomic

O ( 1 ) O(1)O(1)

六、结论部分逐条解释

Atomic floating-point min/max 是现代并发系统的刚需

• GPU / many-core CPU 已大量使用
• 标准滞后于硬件

需要谨慎对待 corner cases

• NaN
• Signed zero
• 浮点比较不满足全序

性能决定一切

Native atomic ≫ CAS loop
尤其在高并发、热点变量上。

语义应贴近硬件现实

P3008 的核心哲学：

不要强行用std::min的“数学完美性”
去约束已经存在的硬件原子语义

提供更精细的 API

例如：

fetch_fminimum fetch_fminimum_num

让用户显式选择 NaN 处理方式

七、一句话总结（可直接放在最后一页）

Atomic 浮点 min/max 的价值不在“语法糖”，
而在于让并发归约真正具备可扩展性。

// ============================================// 可被 Hazard Pointer 机制管理的对象基类// ============================================template<typenameT,typenameD=default_delete<T>>classhazard_pointer_obj_base{public:// retire 的语义：将对象标记为“退休（retired）”//// 含义：// 1. 当前线程声明：我已经不再需要该对象// 2. 对象不会立刻析构（delete）// 3. 对象会被放入 Hazard Pointer 的 retired list// 4. 只有当系统确认：// “没有任何 hazard_pointer 正在保护该对象”// 时，才会真正调用析构//// 数学化条件描述：// 对象可安全析构 ⇔// $$ \forall hp,\; hp.ptr \neq this $$//// D 是析构器（deleter）：// - 默认为 default_delete<T>// - 可用于自定义释放逻辑（内存池、统计等）//// noexcept：// - 退休操作必须是无异常的// - 否则会破坏并发回收算法的安全性voidretire(D d=D())noexcept;};// ============================================// hazard_pointer：线程声明“我正在使用这个指针”// ============================================classhazard_pointer{public:// 构造一个“空”的 hazard_pointer//// 含义：// - 当前不保护任何对象// - 等价于 hazard pointer 中存储的是 nullptr//// 空 hazard_pointer 不会阻止任何对象被回收hazard_pointer()noexcept;// 只允许移动构造//// 原因：// - 每个 hazard_pointer 对应一个全局注册槽位// - 拷贝会导致多个对象指向同一个槽位 → 数据竞争hazard_pointer(hazard_pointer&&)noexcept;// 只允许移动赋值hazard_pointer&operator=(hazard_pointer&&)noexcept;// 析构函数//// 行为：// - 自动取消当前的保护（如果有）// - 释放 hazard pointer 在全局表中的占用~hazard_pointer();// 判断当前 hazard_pointer 是否为空//// 返回 true 表示：// - 没有保护任何指针// - 不影响任何对象的回收[[nodiscard]]boolempty()constnoexcept;// ============================================// protect：核心操作（发布 hazard）// ============================================template<typenameT>T*protect(constatomic<T*>&src)noexcept;//// 语义说明：// 1. 从原子指针 src 中读取一个指针值 p// 2. 将 p 写入当前 hazard_pointer（发布保护）// 3. 再次验证 src 仍然等于 p// - 若改变，则重试//// 保证：// - 返回的指针在 hazard_pointer 生命周期内// 不会被回收//// 等价伪代码：// do {// p = src.load()// hp = p// } while (src.load() != p)//// 这是经典 Hazard Pointer “读-验证”模式// ============================================// try_protect：非阻塞版本的保护// ============================================template<typenameT>booltry_protect(T*&ptr,constatomic<T*>&src)noexcept;//// 行为：// - 尝试一次性建立保护// - 若 src 在过程中发生变化，返回 false//// 适用场景：// - 无锁算法中希望避免自旋// - 更偏向“尝试-失败-回退”逻辑//// 成功返回 true：// - ptr 被成功保护// - 对象在保护期间不会被回收// ============================================// reset_protection：取消保护// ============================================template<typenameT>voidreset_protection(constT*ptr)noexcept;//// 含义：// - 取消对指定 ptr 的保护// - 允许该对象在未来被回收//// 注意：// - 仅取消保护，不会触发立即回收// 取消当前 hazard_pointer 的所有保护//// 等价于：// hp = nullptr//// 常用于：// - 读临界区结束// - 提前释放保护以降低回收延迟voidreset_protection(nullptr_t=nullptr)noexcept;// 交换两个 hazard_pointer//// 语义：// - 交换其底层的保护槽位// - 不影响被保护对象的正确性voidswap(hazard_pointer&)noexcept;};// ============================================// 工厂函数：创建“非空”的 hazard_pointer// ============================================// 构造一个已经分配好全局槽位的 hazard_pointer//// 对比默认构造：// - make_hazard_pointer() → 可立即使用// - hazard_pointer() → 空对象，可能需要后续初始化hazard_pointermake_hazard_pointer();// 交换两个 hazard_pointer 的自由函数版本//// 提供与 std::swap 兼容的接口voidswap(hazard_pointer&,hazard_pointer&)noexcept;

// T 继承自 hazard_pointer_obj_base，// 表示该类型的对象可以被 Hazard Pointer 机制安全回收classT:publichazard_pointer_obj_base<T>{/* T members */};// 原子指针，指向当前“对外可见”的 T 对象// 多线程同时读写，必须是 std::atomic<T*>std::atomic<T*>src_;// 高频调用的读路径（read path）// 特点：// - 多线程并发调用// - 必须无锁 / 极低开销// - 不能阻塞 update()// - 不能访问已被释放的对象template<typenameFunc>UreadAndAccess(Func userFn){// Called frequently// 创建一个 hazard_pointer//// 语义：// - 在全局 hazard pointer 表中占用一个槽位// - 用于声明“我正在使用某个对象”//// 生命周期：// - 从这里开始，到函数结束// - 在此期间，被保护的对象禁止回收hazard_pointer hp=make_hazard_pointer();// Construct hazard pointer.// 从原子指针 src_ 中读取当前对象指针，并建立保护//// protect 的关键保证：// 1. 读取 src_// 2. 将读取到的指针发布到 hazard pointer// 3. 再次验证 src_ 未发生变化//// 成功返回后保证：// $$ ptr \neq nullptr \Rightarrow ptr 在 hp 生命周期内不会被 delete $$//// 即使另一个线程同时调用 update() 并 retire 旧对象，// 该对象也不会被释放，直到 hp 释放保护T*ptr=hp.protect(src_);// Get pointer to a protected object.// 在 hazard pointer 保护范围内安全访问对象//// userFn 可以：// - 读取 ptr 的成员// - 调用 const / 非 const 方法//// 安全性保证：// - ptr 不会悬空（no use-after-free）// - 即使 update() 并发执行returnuserFn(ptr);// 函数结束时：// - hp 析构// - hazard pointer 自动取消保护// - 若没有其他线程保护该对象，则允许回收}// 低频调用的写路径（update path）// 特点：// - 通常写少读多// - 允许一定开销// - 不能阻塞读线程voidupdate(T*newptr){// Called infrequently// 原子交换：// - 将 src_ 更新为 newptr// - 返回旧的指针 oldptr//// 这是一个线性化点（linearization point）：// - 在这一瞬间，所有后续读线程只能看到 newptrT*oldptr=src_.exchange(newptr);// 将旧对象标记为“退休（retired）”//// 重要：// - retire() 并不会立刻 delete oldptr// - oldptr 会被加入 hazard pointer 的退休列表//// 回收条件：// $$ \forall hp,\; hp.ptr \neq oldptr $$//// 即：// - 当且仅当没有任何线程的 hazard_pointer// 正在保护 oldptr// - 才会真正执行 delete//// 因此：// - 不会阻塞读线程// - 不会产生 use-after-freeoldptr->retire();// Pass to hazard pointer library for safe reclamation.}

一、Hazard Pointer 是什么？（一句话版）

Hazard Pointer（危险指针）是一种无锁内存回收机制，用来保证：
当一个线程正在使用某个动态对象时，其他线程不会把它释放掉。
核心目标只有一个：
Use-after-free ⇒ 避免 \text{Use-after-free} \Rightarrow \text{避免}Use-after-free⇒避免

二、C++26 中 Hazard Pointers 的背景

Hazard pointers protect dynamic objects from being reclaimed, allowing safe access to protected objects without additional synchronization
逐句拆解：

• protect dynamic objects
  保护的是动态分配对象（heap object）
• from being reclaimed
  防止它们被回收（delete / free）
• allowing safe access
  允许线程安全地访问对象
• without additional synchronization
  不需要 mutex / lock / refcount

用公式表示这个保证

如果线程T i T_iTi​声明：
H P i = p HP_i = pHPi​=p
那么系统必须保证：
∀ t ∈ [ protect , unprotect ] , p 不会被 reclaim \forall t \in [\text{protect}, \text{unprotect}],\quad p \text{ 不会被 reclaim}∀t∈[protect,unprotect],p不会被reclaim

三、图中流程的整体含义（非常重要）

你给的 SVG 实际上是Hazard Pointer 的完整生命周期图，分成左右两条“时间线”。

左侧（读线程 / 使用线程）

这是fast path，几乎是纳秒级（< 1ns）。

1⃣ Protect object（保护对象）

hp.store(ptr);

含义：

• 把指针ptr发布到线程本地 hazard slot
• 告诉系统：

  “我现在要用这个对象了，别删”
  这是一个非常短的原子操作。

2⃣ Use object（使用对象）

图中绿色的大块区域：

// 任意读操作autox=ptr->field;ptr->method();

关键点：

• 可以很长
• 可以无锁
• 可以跨函数
• 不需要再同步

3⃣ Unprotect object（取消保护）

hp.clear();

表示：

“我不用它了，你们可以考虑回收了”

左侧时间特征

图中标注：

• < 1 ns
• ~ 0 ns
  说明：

Hazard Pointer 的读路径几乎是“零成本”
这就是它存在的意义。

四、右侧（写线程 / 删除线程）

这是slow path，但异步 + 均摊。

4⃣ Remove object（逻辑删除）

list.remove(node);

• 从数据结构中断开
• 但不 delete
  此时：
  object is unreachable but still alive \text{object is unreachable but still alive}object is unreachable but still alive

5⃣ Retire object（标记为待回收）

retire(node);

含义：

“这个对象不再被任何结构引用，但可能还有线程在用”
对象进入retired list。

6⃣ Reclaim object（真正回收）

deletenode;

发生条件：
∀ H P i , H P i ≠ n o d e \forall HP_i,\quad HP_i \neq node∀HPi​,HPi​=node
也就是说：

没有任何 hazard pointer 指向它

右侧时间特征

图中标注：

• asynchronous
• amortized
  说明：
• 回收不在关键路径
• 成本被分摊
• 不阻塞读线程

五、Hazard Pointer 的核心不变量（Invariant）

整个机制围绕一个不变量：
( ∃ H P i = p ) ; ⇒ ; p must not be reclaimed (\exists\ HP_i = p) ;\Rightarrow; p \text{ must not be reclaimed}(∃HPi​=p);⇒;pmust not be reclaimed
反过来：
p can be reclaimed ; ⇔ ; ( ∀ H P i , H P i ≠ p ) p \text{ can be reclaimed} ;\Leftrightarrow; (\forall HP_i,\ HP_i \neq p)pcan be reclaimed;⇔;(∀HPi​,HPi​=p)

六、为什么这对 C++ 标准很重要？

在 C++26 之前：

• Hazard Pointer：
  • 每家自己实现
  • API 不统一
  • 很难写泛型无锁结构
    C++26 引入标准化版本意味着：
• lock-free 容器可以进标准库
• 用户代码不用关心回收细节
• 编译器 / 库可以优化实现

七、“Hazard Pointer Extensions beyond C++26” 在暗示什么？

这是你标题里最有意思的一行。

暗示的方向包括（但不限于）：

1⃣ 更通用的回收策略

• epoch-based reclamation
• hybrid HP + epoch
• NUMA-aware HP

2⃣ 更强的语言集成

• 编译器自动插入 protect / unprotect
• 基于生命周期分析
• 与std::atomic_ref、std::rcu协作

3⃣ 更低开销的实现

• 减少全局扫描
• cache-line 友好布局
• 每核 hazard domain

八、Hazard Pointer vs 其他方案（简表）

九、一句话总结（非常关键）

Hazard Pointer 的本质不是“延迟删除”，
而是：把“对象是否还能被释放”的判断，
从“时间”变成“是否被任何线程声明正在使用”。
用一句公式收尾：
$$
\text{Memory Safety} =
\text{Explicit Usage Declaration}

• \text{Deferred Reclamation}
  $$

一、hazard_pointer_obj_base：把“可回收性”挂到对象上

template<typenameT,typenameD=default_delete<T>>classhazard_pointer_obj_base{voidretire(D d=D())noexcept;};

1⃣ 设计目的

这是一个CRTP 基类，让对象具备：

“我可以被 hazard pointer 系统安全回收”的能力。
关键点：

• T：真实对象类型
• D：删除器（支持自定义 allocator）

2⃣retire()的真实语义

oldptr->retire();

并不等于 delete。
而是：
retire ( p ) ⇒ p ∈ RetiredList \text{retire}(p) \Rightarrow p \in \text{RetiredList}retire(p)⇒p∈RetiredList
表示：

这个对象逻辑上已经死亡，但物理内存是否释放要等安全时机

二、hazard_pointer：读线程使用的保护工具

classhazard_pointer{hazard_pointer()noexcept;// emptyhazard_pointer(hazard_pointer&&)noexcept;hazard_pointer&operator=(hazard_pointer&&)noexcept;~hazard_pointer();

1⃣ RAII + move-only

• 不可拷贝
• 可移动
• 析构时自动 unprotect
  保证：
  scope end ⇒ unprotect \text{scope end} \Rightarrow \text{unprotect}scope end⇒unprotect

2⃣ 查询状态

[[nodiscard]]boolempty()constnoexcept;

• 是否未绑定任何 hazard slot
• 用于调试 / 复用

3⃣ 核心：protect

template<typenameT>T*protect(constatomic<T*>&src)noexcept;

语义

这是经典 HP 循环的标准封装：
伪代码：

do{p=src.load();hp.store(p);}while(src.load()!=p);returnp;

数学表达：
p = protect ( s r c ) ⇒ { p = s r c p 已被 hazard 保护 p = \text{protect}(src) \Rightarrow \begin{cases} p = src \\ p \text{ 已被 hazard 保护} \end{cases}p=protect(src)⇒{p=srcp已被hazard保护​

4⃣try_protect：非阻塞版本

template<typenameT>booltry_protect(T*&ptr,constatomic<T*>&src)noexcept;

• 如果src改变，返回false
• 不自旋
• 适合低延迟路径

5⃣ 手动重置保护

template<typenameT>voidreset_protection(constT*ptr)noexcept;voidreset_protection(nullptr_t=nullptr)noexcept;

用途：

• 同一个hazard_pointer保护不同对象
• 显式声明“我不用这个对象了”

6⃣swap：高效管理 hazard slot

voidswap(hazard_pointer&)noexcept;

• O(1)
• 无额外同步

7⃣ 创建非空 hazard pointer

hazard_pointermake_hazard_pointer();

区别于默认构造：

• 分配 hazard slot
• 注册到 HP 域

三、完整使用示例解析（非常重要）

1⃣ 可回收对象类型

classT:publichazard_pointer_obj_base<T>{/* T members */};

意义：

T 的生命周期由 Hazard Pointer 系统管理

2⃣ 共享原子指针

std::atomic<T*>src_;

这是无锁结构的入口指针。

3⃣ 高频读路径（fast path）

UreadAndAccess(Func userFn){hazard_pointer hp=make_hazard_pointer();T*ptr=hp.protect(src_);returnuserFn(ptr);}

行为分解

1. 分配 hazard slot（一次性）
2. 保护src_当前值
3. 在保护期内安全使用
   重要不变量：
   userFn ( p t r ) 执行期间 p t r 不会被 delete \text{userFn}(ptr) \text{ 执行期间 } ptr \text{ 不会被 delete}userFn(ptr)执行期间ptr不会被delete

4⃣ 低频写路径（slow path）

voidupdate(T*newptr){T*oldptr=src_.exchange(newptr);oldptr->retire();}

行为分解

• 原子替换
• 把旧对象交给 HP 系统
• 不阻塞读线程
  数学形式：
  exchange ⇒ logical remove \text{exchange} \Rightarrow \text{logical remove}exchange⇒logical remove
  retire ⇒ eventual reclaim \text{retire} \Rightarrow \text{eventual reclaim}retire⇒eventual reclaim

四、Hazard Pointer 的正确性不变量（再次强调）

整个系统只依赖一个条件：
( ∃ H P i = p ) ⇒ p must not be reclaimed (\exists\ HP_i = p) \Rightarrow p \text{ must not be reclaimed}(∃HPi​=p)⇒pmust not be reclaimed
而回收条件是：
p reclaimed ⟺ ( ∀ H P i , H P i ≠ p ) p \text{ reclaimed} \iff (\forall HP_i,\ HP_i \neq p)preclaimed⟺(∀HPi​,HPi​=p)

五、P3135R1：Hazard Pointer 扩展提案（beyond C++26）

你给的内容已经是委员会讨论层级的东西了。

1⃣ 不需要扩展的部分

● Protection Counting

• 多 hazard 指向同一对象
• 已可在库层实现
• 不需要语言支持

● Asynchronous Reclamation Execution

• 目前的设计已经是：
  • 异步
  • 均摊
• 标准不强制执行策略

2⃣ 提议中的标准扩展

Synchronous reclamation（同步回收）

含义：

“在确定安全时，立即回收，而不是排队”
数学条件：
∀ H P i , H P i ≠ p ; ⇒ ; delete ( p ) \forall HP_i,\ HP_i \neq p ;\Rightarrow; \text{delete}(p)∀HPi​,HPi​=p;⇒;delete(p)
用途：

• 低内存环境
• 实时系统
• 确定性延迟

Batch creation and destruction（批量创建 / 销毁）

目的：

• 降低 hazard slot 管理开销
• 提高 cache locality
• 提供批量 API
  例如：

autohps=make_hazard_pointers<N>();

3⃣ 为什么这些没进 C++26？

原因很现实：

• ABI / API 稳定性风险
• 实现复杂度
• 各家库已有不同实现
  委员会选择：

先标准化“最小可用、可证明正确”的核心

六、Hazard Pointer 在 C++ 生态中的地位

你现在看到的是：

• 第一次把无锁内存回收正式带入标准
• 为 lock-free 容器铺路
• 为 future RCU / Epoch 奠基

七、一句话总结（终局版）

C++26 Hazard Pointers 把“我正在用这个对象”
从隐含的时间假设，变成了显式、可验证的协议。
最终公式：
$$
\text{Safety} =
\text{Explicit Protection}

• \text{Deferred Reclamation}
  $$

一、为什么不需要扩展 C++26 的部分

1⃣ Protection Counting（保护计数）

含义是什么？

Protection Counting指的是：

同一个对象被多个 hazard pointer 同时保护，需要记录“被保护的次数”。
形式化表示：
prot_count ( p ) = # H P i ∣ H P i = p \text{prot\_count}(p) = \#{ HP_i \mid HP_i = p }prot_count(p)=#HPi​∣HPi​=p

为什么不需要进入标准？

原因有三层：

1. Hazard Pointer 的安全性不依赖计数

HP 的基本不变量是：
( ∃ H P i = p ) ⇒ p 不能被回收 (\exists HP_i = p) \Rightarrow p \text{ 不能被回收}(∃HPi​=p)⇒p不能被回收
而不是：
prot_count ( p ) > 0 \text{prot\_count}(p) > 0prot_count(p)>0
只要知道有没有人保护，而不是有多少人保护。

2. 计数可以完全在库内部实现

例如：

• 扫描所有 hazard slot
• 用哈希表 / 排序数组统计
• 不影响用户 API

3. 不同实现策略差异极大

• per-object 计数
• per-domain 批量统计
• 线程本地缓存
  如果标准化，反而限制实现自由度。

结论

Protection Counting 是“实现细节”，不是“语言或库语义”。

2⃣ Execution of Asynchronous Reclamation（异步回收执行）

含义是什么？

指的是：

何时、在哪个线程执行真正的delete
例如：

• 写线程
• 后台 GC 线程
• 某次 retire 时顺带执行

为什么不需要标准化？

1. 语义已完全确定

HP 已经规定：
p reclaim ⟺ ( ∀ H P i , H P i ≠ p ) p \text{ reclaim} \iff (\forall HP_i,\ HP_i \neq p)preclaim⟺(∀HPi​,HPi​=p)
什么时候做、谁来做，不影响正确性。

2. 应用场景差异巨大

3. 标准只需定义“允许”，不需定义“如何执行”

这符合 C++ 一贯哲学：

Standard defineswhat, nothow.

结论

异步回收是策略问题，不是接口问题。

二、为什么需要扩展的部分

下面是P3135R1 的核心动机。

三、扩展 1：Synchronous Reclamation（同步回收）

1⃣ 现状问题（C++26）

当前 C++26 HP 是：

• 必然异步
• 最终回收
• 无时间保证
  形式化：
  p ∈ RetiredList ⇒ ∃ t , delete ( p ) at time t p \in \text{RetiredList} \Rightarrow \exists t,\ \text{delete}(p) \text{ at time } tp∈RetiredList⇒∃t,delete(p)at timet
  但t 未定义。

2⃣ 同步回收要解决什么？

有些系统不能接受“以后再回收”：

• 实时系统（RTOS）
• 嵌入式（内存极小）
• 确定性延迟系统
  他们希望：

“如果现在没人用，我现在就删。”

3⃣ 同步回收的语义

同步回收意味着：
( ∀ H P i , H P i ≠ p ) ⇒ delete ( p ) 立即执行 (\forall HP_i,\ HP_i \neq p) \Rightarrow \text{delete}(p) \text{ 立即执行}(∀HPi​,HPi​=p)⇒delete(p)立即执行
即：

• retire 时
• 或显式调用时
• 阻塞检查 hazard slots
• 若安全 → 立刻回收

4⃣ 为什么这是“扩展”，而不是默认？

因为代价很大：

• 需要全局扫描
• 破坏 lock-free 的进度保证
• 可能引入延迟抖动

5⃣ 设计取舍总结

四、扩展 2：Batch Creation and Destruction（批量创建 / 销毁）

1⃣ 现状问题（C++26）

当前：

hazard_pointer hp=make_hazard_pointer();

每次：

• 分配 hazard slot
• 注册
• 析构时回收
  在高频路径中，开销不可忽略。

2⃣ 批量 API 的核心思想

一次性做：
H P 1 , H P 2 , … , H P n {HP_1, HP_2, \dots, HP_n}HP1​,HP2​,…,HPn​
而不是：
H P 1 + H P 2 + ⋯ + H P n HP_1 + HP_2 + \dots + HP_nHP1​+HP2​+⋯+HPn​

3⃣ 性能优势

① amortized 成本

cost ∗ b a t c h ≪ n × cost ∗ s i n g l e \text{cost}*{batch} \ll n \times \text{cost}*{single}cost∗batch≪n×cost∗single

② cache locality

• hazard slots 连续存储
• 扫描时顺序访问
• 减少 cache miss

③ 更适合算法级结构

例如：

• 一次遍历多个指针
• 树 / 图算法
• 多指针一致性保护

4⃣ 为什么这是标准级别的扩展？

因为它影响：

• API 形态
• 生命周期管理
• 可移植性
  库作者没法在不暴露接口的情况下通用实现。

五、P3135R1 的整体定位

一句话：

C++26 给了“正确性下限”，P3135R1 给“工程可控性”。

总结表（终局版）

// ---------------- 第一种情况：析构函数不依赖外部资源 ----------------template<classT>classContainer{// Obj 继承自 hazard_pointer_obj_base// 表示 Obj 的生命周期由 Hazard Pointer 机制管理// retire() 后并不会立即 deleteclassObj:hazard_pointer_obj_base<Obj>{T data;// 实际存储的数据/* etc */// 其它成员};// 向容器中插入一个新对象voidinsert(T data){// 动态分配一个 Obj// 此时对象处于“活跃（live）”状态Obj*obj=newObj(data);/* etc */// 将 obj 挂入容器的内部数据结构}// 从容器中删除对象voiderase(Args args){// 查找要删除的对象Obj*obj=find(args);/* Remove obj from container */// 从容器逻辑结构中移除 obj// 从这一刻起，后续读线程不再能通过容器访问到它// 将对象标记为“退休（retired）”//// 重要语义：// - retire() 只是声明“我不再需要这个对象”// - 并不会立刻执行 delete// - 实际析构发生的时间是不确定的//// 对象只有在：// 所有线程都不再持有指向它的 hazard_pointer// 时，才会真正被销毁obj->retire();}};// A 类型的析构函数classA{// 析构函数不依赖任何具有独立生命周期的外部资源// 即：// - 不访问全局对象// - 不访问已销毁的系统资源// - 不依赖作用域外状态~A();};// 使用容器的作用域{Container<A>container;container.insert(a);container.erase(a);}// 注意：// 包含 A 的 Obj 可能此时尚未被 delete//// 但这是“安全的”，因为：// - A 的析构函数不依赖任何外部资源// - 即使析构发生在容器作用域之后，也不会触发未定义行为//// 因此：// Hazard Pointer 的“异步回收”在该场景下是 OK 的

// ---------------- 第二种情况：析构函数依赖外部资源 ----------------template<classT>classContainer{// 同样的 Hazard Pointer 管理对象classObj:hazard_pointer_obj_base<Obj>{T data;/* etc */};voidinsert(T data){Obj*obj=newObj(data);/* etc */}voiderase(Args args){Obj*obj=find(args);/* Remove obj from container */// 从容器中逻辑删除对象// retire() 仍然是“异步”的// 对象可能在将来的任意时间才被真正 deleteobj->retire();}};// B 类型的析构函数classB{// 析构函数依赖具有独立生命周期的外部资源//// 例如：// - 全局状态// - 线程池// - IO 资源// - GPU / NUMA / 外部系统资源~B(){use_resource_XYZ();}};// 构造外部资源make_resource_XYZ();{Container<B>container;container.insert(b);container.erase(b);}// 关键问题：// 包含 B 的 Obj 可能此时仍然尚未被 delete//// Hazard Pointer 的异步回收意味着：// - B::~B() 的调用时间不确定// - 可能发生在 container 作用域结束之后// - 甚至发生在 destroy_resource_XYZ() 之后//// 如果析构在此之后发生：destroy_resource_XYZ();// 这将导致：// - use_resource_XYZ() 访问已经销毁的资源// - 产生未定义行为（UB）//// 结论：// 在这种情况下，仅有“异步回收”的 Hazard Pointer 是不够的// 需要“同步回收（Synchronous Reclamation）”机制

一、Hazard Pointer 是在解决什么问题？

**Hazard Pointer（风险指针）**是一种无锁数据结构的内存回收机制，核心目标是：

在并发读线程仍可能访问对象的情况下，安全地延迟删除对象。
形式化描述可以理解为：
对象o oo只有在
∀ t ∈ T h r e a d s , o ∉ H a z a r d ( t ) \forall t \in Threads, o \notin Hazard(t)∀t∈Threads,o∈/Hazard(t)
时，才允许被真正析构（delete）。

二、Synchronous vs Asynchronous Reclamation（同步 vs 异步回收）

1⃣ Asynchronous Reclamation（异步回收）

• retire()只是标记对象“可以回收”
• 真正的delete：
  • 发生在未来某个不确定时间
  • 由后台扫描 / 其他线程触发
• 关键特性：

erase 返回 ≠ 对象已析构

2⃣ Synchronous Reclamation（同步回收）

语义要求：

当一个作用域结束 / 操作完成时
对象已经被析构
形式化语义可以理解为：
erase ( o ) ⇒ ∃ t 0 , ∀ t > t 0 , o 不再存在 \text{erase}(o) \Rightarrow \exists t_0, \forall t > t_0, o \text{ 不再存在}erase(o)⇒∃t0​,∀t>t0​,o不再存在

三、C++26 的现状：只支持异步回收

C++26 Hazard Pointer 标准接口：只保证 Asynchronous Reclamation
这意味着：

obj->retire();

只保证：

• 当前线程以后不再访问
• 其他线程 hazard pointer 清空后某个时刻delete
  不保证 erase 返回时对象已经析构

四、第一个例子：class A—— 为什么是 OK？

场景回顾

• A::~A()不依赖外部资源
• 即使析构发生得晚一点，也没有副作用

{Container<A>container;container.insert(a);container.erase(a);}// Obj containing 'a' may be not deleted yet.

结论

• 对象A延迟析构
• 程序语义仍然正确
  异步回收是“可接受的”

五、第二个例子：class B—— 为什么会出错？

关键区别

~B(){use_resource_XYZ();}

• B的析构依赖一个独立生命周期的外部资源
• 资源在 container 作用域之后被销毁：

destroy_resource_XYZ();

问题根源

逻辑顺序实际上变成了：

1. container.erase(b)→retire()（未 delete）
2. Container<B>离开作用域
3. destroy_resource_XYZ()
4. 某个时刻才 delete Obj
5. ~B()访问已销毁的资源

错误的本质

析构时序不受控
可以用一个时序不等式表达：
d e s t r o y r e s o u r c e X Y Z ( ) < ∼ B ( ) destroy_resource_XYZ() < \sim B()destroyr​esourceX​YZ()<∼B()
这是未定义行为（UB）。

六、为什么“需要 Synchronous Reclamation”？

你的图里写得非常精准：

Need Synchronous Reclamation
原因是：

• 析构函数有副作用
• 副作用依赖外部生命周期
• 必须保证：
  ∼ B ( ) < d e s t r o y r e s o u r c e X Y Z ( ) \sim B() < destroy_resource_XYZ()∼B()<destroyr​esourceX​YZ()

七、Hazard Pointer 的解决方案：Cohort（队列/批次）

1⃣hazard_pointer_cohort的语义

可以把 cohort 理解为：

一个“我负责清空”的退休对象集合
特点：

• cohort 析构时：
  • 必须保证其内所有 retire 的对象都已被真正 delete
• 是同步屏障

2⃣ API 语义

obj->retire_to_cohort(cohort_);

表示：

把对象的最终删除责任，绑定到cohort_的生命周期

八、最终修正后的正确模式（逐步解释）

Container 增加 cohort

hazard_pointer_cohort cohort_;

语义：

• Container的析构 =同步回收点

erase 中的关键变化

obj->retire_to_cohort(cohort_);ex_.submit([]{asynchronous_reclamation();});

含义分解：

1. 逻辑删除：从容器中移除
2. 绑定回收责任：加入 cohort
3. 触发异步扫描：加速 hazard 清理

生命周期保证

{Container<B>container;container.insert(b);container.erase(b);}// Container 析构// cohort 析构// => 所有 Obj<B> 已 deletedestroy_resource_XYZ();

满足严格时序：
∼ B ( ) < d e s t r o y r e s o u r c e X Y Z ( ) \sim B() < destroy_resource_XYZ()∼B()<destroyr​esourceX​YZ()
完全正确

九、总结对比（核心要点）

十、一句话总结（论文式）

Hazard Pointer 的异步回收足以保证内存安全，但无法保证析构时序；当析构函数依赖独立生命周期资源时，必须引入基于 cohort 的同步回收语义。
如果你愿意，我可以下一步帮你做：

• Hazard Pointer vs Epoch / RCU 的同步能力对比
• 为什么标准先只给异步（委员会角度）
• 用 Rust / C++ RAII 的视角重新解释 cohort

// hazard_pointer_cohort：Hazard Pointer 的“同步回收分组”对象//// 语义核心：// - cohort 表示一个“回收边界（reclamation boundary）”// - 所有被 retire_to_cohort() 绑定到该 cohort 的对象// 必须在 cohort 析构之前被真正 delete//// 作用：// - 将 Hazard Pointer 从“最终会回收（asynchronous）”// 提升为“在此之前必须回收（synchronous）”classhazard_pointer_cohort{// 构造一个 cohort//// 构造完成后：// - 可以向该 cohort 绑定 retired 对象// - cohort 本身通常作为一个作用域对象存在hazard_pointer_cohort()noexcept;// 禁止拷贝构造//// 原因：// - cohort 表示一个严格的生命周期边界// - 拷贝会导致“一个回收边界对应多个实体”// - 会破坏以下不变量：// $$ \text{~cohort} \Rightarrow \text{所有对象已回收} $$hazard_pointer_cohort(consthazard_pointer_cohort&)=delete;// 禁止移动构造//// 原因同样是为了保证：// - cohort 的身份唯一// - cohort 的析构点明确且不可转移hazard_pointer_cohort(hazard_pointer_cohort&&)=delete;// 禁止拷贝赋值hazard_pointer_cohort&operator=(consthazard_pointer_cohort&)=delete;// 禁止移动赋值hazard_pointer_cohort&operator=(hazard_pointer_cohort&&)=delete;// cohort 的析构函数（同步回收的关键）//// 析构语义：// 1. 触发一次或多次 hazard pointer 扫描// 2. 等待所有线程释放对 cohort 中对象的保护// 3. 确保 cohort 中所有对象已被真正 delete//// 形式化保证：// $$ \forall obj \in cohort,\; \text{delete}(obj) \text{ 已发生} $$//// 也就是说：// - 当 ~hazard_pointer_cohort() 返回时// - 不再存在任何“延迟析构”的对象~hazard_pointer_cohort();};// hazard_pointer_obj_base：可被 Hazard Pointer 管理的对象基类//// T：实际对象类型// D：自定义删除器（默认使用 default_delete<T>）//// 提供 retire_to_cohort()，用于“同步回收”场景template<classT,classD=default_delete<T>>classhazard_pointer_obj_base{// 将对象退休（retire），并显式绑定到某个 cohort//// 语义：// - 对象从逻辑结构中移除// - 加入 hazard pointer 的 retired 列表// - 并归属于给定的 cohort//// 与 retire()（异步）最大的区别：// - retire()：析构时间不确定// - retire_to_cohort()：析构必须发生在 cohort 析构之前//// 数学化表达：// $$ \text{delete}(obj) \le \text{~cohort} $$//// noexcept 的原因：// - 回收路径通常在并发代码中// - 不允许异常破坏内存回收不变量voidretire_to_cohort(hazard_pointer_cohort&,D d=D())noexcept;};// 显式触发一次“异步回收”流程//// 作用：// - 扫描所有 hazard pointer// - 回收当前已满足条件的 retired 对象//// 使用场景：// - 后台线程周期性调用// - executor / 线程池任务// - cohort 析构前的辅助回收//// 注意：// - 该函数本身仍然是“异步回收”// - 只有结合 hazard_pointer_cohort 才能形成同步回收语义voidasynchronous_reclamation()noexcept;// 相关实现与参考资料：//// - Facebook Folly 实现：// folly/synchronization/Hazptr.h//// - CPPCON 2021 演讲：// Hazard Pointer Synchronous Reclamation//// 这些内容构成了该 Possible API 的实践基础// Possible API（可能的标准 API 形态）//// - synchronous：// 使用 hazard_pointer_cohort + retire_to_cohort()// 提供“作用域内完成回收”的强保证//// - asynchronous：// 传统 Hazard Pointer 模型// 提供“最终会回收”的弱保证//// 两者并存，使 Hazard Pointer 既能高性能，// 又能安全处理析构依赖外部资源的复杂类型

Hazard Pointer Synchronous Reclamation（风险指针的同步回收）

背景动机

传统的Hazard Pointer（HP）机制只保证：

对象不会在仍被线程访问时被释放
但并不保证对象何时被释放。
因此，标准 Hazard Pointer 属于：
Asynchronous Reclamation（异步回收）
形式化地说：
retire ( o b j ) ⇒ ∃ t ≥ t 0 , delete ( o b j ) \text{retire}(obj) \Rightarrow \exists t \ge t_0, \text{delete}(obj)retire(obj)⇒∃t≥t0​,delete(obj)
即：
对象最终会被删除，但具体时间不确定。

同步回收要解决的问题

在某些场景中，析构函数依赖外部资源的生命周期（例如线程池、全局状态、硬件资源等），这要求：
delete ( o b j ) ≤ 资源销毁时刻 \text{delete}(obj) \le \text{资源销毁时刻}delete(obj)≤资源销毁时刻
也就是说：

在离开某个作用域之前，必须确保对象已经被真正析构
这正是Hazard Pointer Synchronous Reclamation要解决的问题。

Cohorts（回收分组）的核心思想

Cohort（回收组）是同步回收的关键抽象：

把一批 retired 对象绑定到一个作用域，当该作用域结束时，强制完成这些对象的回收。
可以理解为：
“这些对象必须在我走之前全部安全 delete。”

hazard_pointer_cohort—— 同步回收的作用域对象

classhazard_pointer_cohort{hazard_pointer_cohort()noexcept;hazard_pointer_cohort(consthazard_pointer_cohort&)=delete;hazard_pointer_cohort(hazard_pointer_cohort&&)=delete;hazard_pointer_cohort&operator=(consthazard_pointer_cohort&)=delete;hazard_pointer_cohort&operator=(hazard_pointer_cohort&&)=delete;~hazard_pointer_cohort();};

语义说明

• 构造一个回收分组（cohort）
• 该 cohort 表示：
  • 所有“归属于该 cohort 的对象”
  • 必须在 cohort 析构前被安全回收

为什么禁止拷贝 / 移动？

hazard_pointer_cohort(consthazard_pointer_cohort&)=delete;hazard_pointer_cohort(hazard_pointer_cohort&&)=delete;

原因是：

• cohort 表示一个严格的生命周期边界
• 如果允许拷贝 / 移动，会破坏以下不变量：
  cohort 析构 ⇒ 该 cohort 中所有对象已 delete \text{cohort 析构} \Rightarrow \text{该 cohort 中所有对象已 delete}cohort析构⇒该cohort中所有对象已delete

析构函数的关键语义

~hazard_pointer_cohort();

析构时保证：

1. 触发回收流程
2. 等待所有 hazard pointer 解除保护
3. 确保 cohort 中的所有对象已被真正析构
   形式化保证：
   ∀ o b j ∈ cohort , delete ( o b j ) 已发生 \forall obj \in \text{cohort},\quad \text{delete}(obj) \text{ 已发生}∀obj∈cohort,delete(obj)已发生

hazard_pointer_obj_base::retire_to_cohort

template<classT,classD=default_delete<T>>classhazard_pointer_obj_base{voidretire_to_cohort(hazard_pointer_cohort&,D d=D())noexcept;};

语义解释

• 将对象：
  • 标记为 retired
  • 并绑定到指定的 cohort
• 与普通retire()的区别在于：

语义对比（数学化）

异步回收：
retire ( o b j ) ⇒ delete ( o b j ) eventually \text{retire}(obj) \Rightarrow \text{delete}(obj) \text{ eventually}retire(obj)⇒delete(obj)eventually
同步回收（cohort）：
retire_to_cohort ( o b j , c ) ⇒ delete ( o b j ) ≤ c \text{retire\_to\_cohort}(obj, c) \Rightarrow \text{delete}(obj) \le \text{~}cretire_to_cohort(obj,c)⇒delete(obj)≤c

asynchronous_reclamation()

voidasynchronous_reclamation()noexcept;

作用说明

• 显式触发一次：
  • hazard pointer 扫描
  • retired 对象回收
• 常用于：
  • 后台线程
  • executor / 线程池
  • cohort 析构前的辅助清理

同步 vs 异步 API 的设计意图

Asynchronous Reclamation（现行 C++26）

• 简单
• 高吞吐
• 析构时间不可预测
• 不适合析构依赖外部资源的类型

Synchronous Reclamation（Cohorts）

• 稍高开销
• 有确定的回收点
• 析构安全
• 适合复杂系统资源管理

与 Folly 的关系

• Facebook Folly 已有成熟实现：
  • folly/synchronization/Hazptr.h
• CPPCON 2021 专题演讲：
  • Hazard Pointer Synchronous Reclamation
• 该 API 设计基本是：
  • 对 Folly 经验的标准化抽象

总结一句话（可以直接用在结论页）

Hazard Pointer Cohorts 将“最终会回收”升级为“在此之前必须回收”，使 Hazard Pointer 能安全用于析构依赖外部资源的并发系统。
如果你愿意，下一步我可以：

• 把你之前Container<B>的错误例子完整改写成 cohort 版本
• 用一张时间轴图解释cohort 析构时发生了什么
• 对比Hazard Pointer Cohort vs Epoch/RCU
  你只要点一个。

// =======================// Hazard Pointer 同步回收 vs C++26 仅异步回收// =======================//// 核心问题：// Hazard Pointer 的 retire() 只保证“最终会删除”，// 并不保证“在某个确定时间点之前已经删除”。//// 当析构函数依赖外部资源时，这个不确定性会变成严重问题。//// -----------------------// C++26：仅支持【异步回收】（Asynchronous Reclamation）// -----------------------template<classT>classContainer{// Obj 继承 hazard_pointer_obj_base// 说明该对象的生命周期由 Hazard Pointer 框架管理classObj:hazard_pointer_obj_base<Obj>{T data;// 真正存储的数据/* etc */// 其他成员（指针、索引等）};voidinsert(T data){// 分配新对象// 对象一旦被发布给并发读线程，就可能被 hazard pointer 保护Obj*obj=newObj(data);/* etc */// 将 obj 插入到无锁/并发容器中}voiderase(Args args){Obj*obj=find(args);// 查找要删除的对象/* Remove obj from container */// 逻辑删除：从容器结构中移除// 但此时可能仍有其他线程通过 hazard pointer 访问它obj->retire();// retire() 的含义：// 1. 告诉 Hazard Pointer 系统：这个对象“已经不再被容器拥有”// 2. 但并不立刻 delete// 3. 只有当【没有任何 hazard pointer 指向它】时，才允许 delete//// 关键点：// delete 的时间是【不确定的】，可能立刻，也可能很久以后}};classA{// A 的析构函数：// 不依赖任何外部资源// 不访问其他具有独立生命周期的对象//// 因此：// 即使析构被延迟执行，也不会造成逻辑错误或 UB~A();};{Container<A>container;container.insert(a);container.erase(a);}// 重要说明：// 这里 container 已经离开作用域，但：//// Obj(A) 可能仍然没有被 delete// 因为：// - 可能仍有并发线程持有 hazard pointer// - retire() 只是“异步回收”//// 但这是 OK 的：// 因为 A 的析构函数不依赖任何外部资源//// 内存安全// 生命周期语义安全//// 结论：OK// -----------------------// 同步回收（Synchronous Reclamation）// -----------------------//// 目标：// 在“某个确定时间点之前”，强制保证对象已经被 delete//template<classT>classContainer{classObj:hazard_pointer_obj_base<Obj>{T data;/* etc */};// hazard_pointer_cohort：回收分组（回收边界）//// 语义：// 所有 retire_to_cohort(cohort_) 的对象，// 在 cohort_ 析构之前，必须已经被 deletehazard_pointer_cohort cohort_;voidinsert(T data){Obj*obj=newObj(data);/* etc */}voiderase(Args args){Obj*obj=find(args);/* Remove obj from container */obj->retire_to_cohort(cohort_);// retire_to_cohort 的含义：// 1. 对象进入 Hazard Pointer 的退休列表// 2. 同时“绑定”到 cohort_// 3. cohort_ 析构时会阻塞/等待：// 直到该对象真正被 deleteex_.submit([]{asynchronous_reclamation();});// 触发一次异步回收扫描：// - 加快回收进度// - 减少 cohort_ 析构时需要等待的时间//// 注意：// 真正的“同步保证”不是来自这里，// 而是来自 cohort_ 的析构语义}};classB{// B 的析构函数：// 依赖外部资源 XYZ// 该资源拥有独立生命周期//// 如果析构发生在 XYZ 被销毁之后 → UB~B(){use_resource_XYZ();}};make_resource_XYZ();// 创建外部资源 XYZ{Container<B>container;container.insert(b);container.erase(b);}// ← container 离开作用域// 触发成员 cohort_ 的析构// cohort_ 析构时保证：// 所有 retire_to_cohort(cohort_) 的 Obj(B)// 已经：// 没有 hazard pointer 引用// 已经被 delete//// 即：// $$ \forall obj \in cohort,\quad delete(obj) < destroy\_resource\_XYZ $$destroy_resource_XYZ();// 现在销毁资源是安全的// 析构顺序正确// 无 use-after-free// 无 Undefined Behavior//// 结论：OK

一、背景核心问题

Hazard Pointer 的本质目标是：

在无锁并发结构中，保证对象在“仍可能被其他线程访问”时不会被释放。
但是传统 Hazard Pointer（也是C++26 目前仅有的形式）只保证：
对象最终会被删除（eventually deleted） \text{对象最终会被删除（eventually deleted）}对象最终会被删除（eventually deleted）
而不保证“在某个确定时间点之前一定被删除”。

二、第一段：C++26 仅支持的【异步回收（Asynchronous Reclamation）】

template<classT>classContainer{classObj:hazard_pointer_obj_base<Obj>{T data;/* etc */};voidinsert(T data){Obj*obj=newObj(data);/* etc */}voiderase(Args args){Obj*obj=find(args);/* Remove obj from container */obj->retire();}};classA{// Deleter does not depend on resources// with independent lifetime.~A();};{Container<A>container;container.insert(a);container.erase(a);}// Obj containing 'a' may be not deleted yet.

1⃣ 这里发生了什么？

• Obj继承自hazard_pointer_obj_base
• erase()中调用obj->retire()
• 这意味着：
  • 对象逻辑上已从容器移除
  • 但物理释放（delete）被推迟

2⃣retire()的语义

retire()表示：
该对象加入“待回收列表”，等所有 hazard pointer 释放后再 delete \text{该对象加入“待回收列表”，等所有 hazard pointer 释放后再 delete}该对象加入“待回收列表”，等所有hazard pointer释放后再delete
也就是说：

• 若其他线程仍持有 hazard pointer指向该对象
• 删除会被延迟
• 删除发生时间不可预测

3⃣ 为什么对class A是 OK 的？

classA{~A();};

A的析构函数：

• 不依赖任何外部资源
• 不访问：
  • 已释放内存
  • 已销毁的全局/线程资源
• 即使析构被延迟：
  • 语义仍然正确
  • 不会触发 UB
    因此结论是：

对象什么时候被删都无所谓 → OK

三、第二段：引入【同步回收（Synchronous Reclamation）】

template<classT>classContainer{classObj:hazard_pointer_obj_base<Obj>{T data;/* etc */};hazard_pointer_cohort cohort_;voidinsert(T data){Obj*obj=newObj(data);/* etc */}voiderase(Args args){Obj*obj=find(args);/* Remove obj from container */obj->retire_to_cohort(cohort_);ex_.submit([]{asynchronous_reclamation();});}};

1⃣ 新增的关键元素：hazard_pointer_cohort

cohort_表示一个回收边界（reclamation boundary）：

所有 retire 到该 cohort 的对象，必须在 cohort 析构前被删除
形式化描述为：
∀ o b j ∈ c o h o r t , d e l e t e ( o b j ) ≤ cohort \forall obj \in cohort,\quad delete(obj) \le \text{~cohort}∀obj∈cohort,delete(obj)≤cohort

2⃣retire_to_cohort(cohort_)的语义

它不是普通的retire()，而是：

• 把对象加入 hazard pointer 的退休列表
• 同时绑定到 cohort
• cohort 析构时会：
  1. 等待所有 hazard pointer 释放
  2. 强制完成对象回收

3⃣asynchronous_reclamation()的作用

ex_.submit([]{asynchronous_reclamation();});

这一步：

• 加速回收过程
• 提前触发扫描
• 减少 cohort 析构时的阻塞时间
  但注意：

真正的同步保证来自 cohort 的析构，而不是这个函数本身

四、为什么第二段必须使用同步回收？

classB{~B(){use_resource_XYZ();}};

1⃣ 问题本质

B的析构函数：

• 依赖外部资源XYZ
• 且该资源有独立生命周期

make_resource_XYZ();{Container<B>container;container.insert(b);container.erase(b);}destroy_resource_XYZ();

如果使用异步回收：

• erase()只调用retire()
• 对象Obj(B)可能还没被 delete
• destroy_resource_XYZ()已经发生
• 析构~B()再访问XYZ
  结果：
  Use-after-destroy ⇒ Undefined Behavior \text{Use-after-destroy} \Rightarrow \text{Undefined Behavior}Use-after-destroy⇒Undefined Behavior

五、同步回收如何解决？

引入 cohort 后：

hazard_pointer_cohort cohort_;

对象通过：

obj->retire_to_cohort(cohort_);

绑定到 cohort。
当container离开作用域时：

1. ~Container()被调用
2. 成员cohort_析构
3. cohort 保证所有绑定对象已 delete
   因此：

// Obj containing 'b' must be already deleted.destroy_resource_XYZ();

成立。

六、对比总结（核心结论）

七、一句话结论

Hazard Pointer 的异步回收保证“内存安全”，而同步回收（Cohort）保证“生命周期安全”。

// ========================================// Hazard Pointer 批量创建与销毁（Batch Creation and Destruction）// ========================================//// 核心问题：// 在传统单个创建/销毁的方式下，每个 hazard_pointer// 都需要独立分配和初始化，销毁时也单独处理。// 并发性能上有一定开销（如 ~6 ns）。//// C++26 标准（一个一个创建）：{hazard_pointer hp[3];// 声明三条 hazard pointer，但此时它们都是 empty 状态/* Three hazard pointers are made nonempty separately. */hp[0]=make_hazard_pointer();// 分别初始化第 0 个 hazard pointerhp[1]=make_hazard_pointer();// 分别初始化第 1 个 hazard pointerhp[2]=make_hazard_pointer();// 分别初始化第 2 个 hazard pointerassert(!hp[0].empty());// 验证第 0 个已非空assert(!hp[1].empty());// 验证第 1 个已非空assert(!hp[2].empty());// 验证第 2 个已非空/* src is atomic<T*> */T*ptr=hp[0].protect(src);// 通过 hp[0] 获取受保护的对象指针 ptr/* etc */}/* Three nonempty hazard pointers are destroyed separately. */// 退出作用域时，hp[0], hp[1], hp[2] 各自析构，分别清理// 性能：大约 ~6 ns（每条单独处理）// ========================================// 批量创建与销毁（Batch creation and destruction）// ========================================{hazard_pointer hp[3];/* Three hazard pointers are made nonempty together. */make_hazard_pointer_batch(std::span{hp});// 一次性将 hp 数组的三个 hazard pointer 初始化为非空// 相比单个 make_hazard_pointer，多条同时处理，// 内部可能使用批量分配或优化路径 → 性能更优SCOPE_EXIT{destroy_hazard_pointer_batch(std::span{hp});// 批量销毁 hp 数组的三个 hazard pointer// 内部可能一次性释放资源，提高效率};assert(!hp[0].empty());assert(!hp[1].empty());assert(!hp[2].empty());/* src is atomic<T*> */T*ptr=hp[0].protect(src);// 与单个使用方式相同/* etc */}/* Three nonempty hazard pointers are emptied together, and then destroyed separately. */// 批量清空，然后依次析构，性能大约 ~2 ns（明显低于单个创建/销毁）// ========================================// Possible API// ========================================voidmake_hazard_pointer_batch(std::span<hazard_pointer>);// 批量初始化一组 hazard pointer 为非空voiddestroy_hazard_pointer_batch(std::span<hazard_pointer>)noexcept;// 批量销毁一组 hazard pointer// ========================================// 总结// ========================================//// 1. 单个创建/销毁：//// - 每个 hazard pointer 独立初始化、销毁// - 性能：较低 (~6 ns)// - 使用简单，但高并发场景下开销大//// 2. 批量创建/销毁：//// - 一次性初始化多条 hazard pointer// - 内部可优化批量分配// - 销毁时也可批量处理// - 性能：高 (~2 ns)// - 高并发场景更适合//// 3. 使用场景：// - 当你需要频繁创建大量 hazard pointer 时，推荐批量 API// - 单个创建适合偶尔使用或数量较少的情况//

Hazard Pointer 批量创建与销毁理解

背景：

• Hazard Pointer（HP）是一种安全回收机制，用于在多线程环境下安全访问共享对象。
• 当对象可能被其他线程删除时，HP 能保证访问期间对象不会被回收。
• 问题：在高并发场景下，频繁创建和销毁 HP 会带来性能开销。
  • 单个创建/销毁时间大约为6 ns 6\text{ ns}6ns。
  • 批量创建/销毁可降低到大约2 ns 2\text{ ns}2ns，提升 3 倍性能。

单个创建/销毁方式（C++26 默认）

{hazard_pointer hp[3];// 声明三条 HP，初始状态都是 emptyhp[0]=make_hazard_pointer();// 单独初始化第 0 个 HPhp[1]=make_hazard_pointer();// 单独初始化第 1 个 HPhp[2]=make_hazard_pointer();// 单独初始化第 2 个 HPassert(!hp[0].empty());// 确认第 0 个非空assert(!hp[1].empty());// 确认第 1 个非空assert(!hp[2].empty());// 确认第 2 个非空T*ptr=hp[0].protect(src);// 使用 HP 保护 atomic 对象 src}

理解：

1. 每个 HP 都单独分配、初始化和销毁。
2. 创建和销毁都是独立操作，存在性能开销。
3. 适合 HP 数量少、访问不频繁的场景。
4. 高并发下开销明显，因为T ∗ p t r = h p [ i ] . p r o t e c t ( s r c ) T* ptr = hp[i].protect(src)T∗ptr=hp[i].protect(src)频繁调用时，每次都要操作 HP 内部数据结构。

批量创建/销毁方式（Batch Creation and Destruction）

{hazard_pointer hp[3];make_hazard_pointer_batch(std::span{hp});// 一次性批量创建 HPSCOPE_EXIT{// 离开作用域时批量销毁destroy_hazard_pointer_batch(std::span{hp});};assert(!hp[0].empty());assert(!hp[1].empty());assert(!hp[2].empty());T*ptr=hp[0].protect(src);// 使用 HP 保护 atomic 对象 src}