对外 API

rayon-core 的公开函数不多，这一部分把它们逐个拆开。每个函数都是 03 任务与 Latch 里几种零件的组合：选一种 Job 装闭包，推进本地 deque、全局注入队列或每线程的广播队列，再选一种 latch 等它（或者不等）。

flowchart LR
  subgraph block["阻塞：等任务做完才返回"]
    join["join / join_context"]
    scope["scope / scope_fifo / in_place_scope"]
    bc["broadcast"]
    inst["ThreadPool::install"]
  end
  subgraph detach["不阻塞：交出去就返回"]
    sp["spawn / spawn_fifo"]
    sbc["spawn_broadcast"]
  end
  subgraph coop["协作"]
    y["yield_now / yield_local"]
  end
  block --> sj["StackJob 或 HeapJob + 计数 latch"]
  detach --> hj["HeapJob / ArcJob + terminate_count"]
  coop --> fw["find_work / take_local_job 执行一个任务"]

ThreadPool 上的同名方法，阻塞的那几个（join、scope、scope_fifo）都是 self.install(|| 全局函数(..))：先进这个池，再调全局函数；全局函数总是作用于「调用线程所在的池」，不在任何池里就用全局池。install 本身和三条进池路径见 in_worker：从哪进池。

五章：

1. join 与 join_context：主线 1 的全部细节。先推 B 再跑 A；弹回来的正是 B 就内联执行，否则执行它，本地空了就 wait_until；A panic 时也要等 B 做完。实测：join 的固定开销（E1）、等待时偷来的任务和持锁的冲突（E7，含一个确定性复现）。
2. scope 家族：ScopeBase 的三个字段；scope 与 in_place_scope 在哪个线程跑 op；spawn 为什么一律 inject_or_push；'scope 生命周期；panic 只保留第一个（E11）。
3. spawn 与 spawn_fifo：terminate_count 让池在任务跑完前不终止；没有 panic_handler 就 abort（E11）；和 tokio 的 spawn 对照；在 async 代码里调 rayon 的三种写法（E5）。
4. broadcast：每线程一个 FIFO 广播队列，worker 先清自己的广播队列再去偷；一次睡眠竞态的修复（#992）。
5. yield_now 与 yield_local：在 rayon 任务里等条件时，把线程让给 rayon 而不是让给 OS。

本部分的实验

实验目录都在 exp-rayon/ 下，机器是 M2 Max（8 性能核 + 4 能效核），macOS，rustc 1.99.1，--release。

计时类数字（E1、E5、E15）在 1 分钟和 5 分钟负载都低于 3 时取得，各页写了具体负载；E7、E11、E16 是正确性实验，结论不依赖负载，E7 的死锁概率随负载有变化，页面列出了每组的负载。