Rust in Everything
基于 parking_lot 0.13.0

0.13 的变化

本卷正文对着 parking_lot-v0.12.5 写。写作期间上游发布了 0.13.0：tag parking_lot-v0.13.0、parking_lot_core-v0.10.0、lock_api-v0.5.0 都指向提交 1a5c3dd（2026-10-21）。它和 0.12.5 之间有 89 个提交，src/、core/src/、lock_api/src/ 合计 +5578 / −4176 行，22 个合并提交。这一部分把差别汇总在一起，正文里只在相关的地方放一句「0.13 起不同」并链到这里。

依据：0.13.0 的 CHANGELOG（0.13.0 一节，引文都出自这里）和 git log --merges parking_lot-v0.12.5..parking_lot-v0.13.0。PR 号以合并提交为准；#533 是一个合并了 38 个提交的 PR（合并提交 6be7fac，标题「Merge pull request #533」，分支名 bug-fixes），下文写成「#533 中的 xxxxxxx」。

flowchart LR
  v125["0.12.5<br/>core 0.9.12 / lock_api 0.4.14"] --> pr499["#499 WordLock 用 AtomicPtr<br/>MSRV 1.84"]
  pr499 --> pr520["#520 Once::new_completed"]
  pr520 --> pr524["#524 into_inner_with_raw"]
  pr524 --> pr523["#523 Condvar 进 lock_api"]
  pr523 --> pr533["#533 bug-fixes（38 个提交）<br/>MSRV 1.95、去掉 eventual fairness / HLE、RecursiveRwLock"]
  pr533 --> pr544["#544 每次加锁的守卫状态"]
  pr544 --> pr545["#545 先放锁再叫醒"]
  pr545 --> pr540["#540 SpinWait 计数"]
  pr540 --> pr549["#549 L4Re"]
  pr549 --> pr538["#538 WASI 走 pthread"]
  pr538 --> v130["0.13.0<br/>core 0.10.0 / lock_api 0.5.0"]

总表

#改动出处对用户的影响本卷受影响的章
①延后唤醒：解锁时先放锁，再去叫醒停车的线程。CHANGELOG：「Signficantly improved Mutex and RwLock performance under contention by deferring waking up parked threads until after the lock is released.」#545（合并 7d6524c），提交 79f4ce9「Release mutex and rwlock ownership before waking waiters」有竞争时吞吐提高；API 不变RawMutex 的一字节状态机、读、写与写者优先；详见 延后唤醒与守卫状态
②每次加锁的守卫状态：RawMutex::Guard 取代 GuardMarker，RwLock 分 SharedGuard / ExclusiveGuard / UpgradableGuard，unlock 消费它#544（合并 8a480d6），提交 df8e469「Add per-acquisition guard state to raw locks」只用 parking_lot::Mutex 的代码不受影响；自己实现 lock_api trait 的 crate 必须改06 全部，见 延后唤醒与守卫状态
③去掉自动的最终公平。CHANGELOG：「Removed automatic eventual fairness. Fair unlocking remains available through the explicit fair-unlock APIs. This removes UnparkResult::be_fair.」#533 中的 8cfdedb「Remove eventual fairness」长临界区、放锁后立即重新加锁的线程可能长时间独占；依赖过 0.12 行为的要改用 unlock_fair / FairMutexeventual fairness；详见 去掉的与修正的
④去掉 hardware-lock-elision feature#533 中的 16ebdb7「Remove hardware lock elision support」开了这个 feature 的依赖会编译失败（feature 不存在）状态字与两条队列
⑤RecursiveRwLock：「Replaced the recursive read methods on RwLock with a dedicated reader-biased RecursiveRwLock type. The RawRwLockRecursive and RawRwLockRecursiveTimed extension traits have been removed from lock_api.」#533 中的 8150554「Add dedicated recursive reader-writer lock」read_recursive 的调用点要改类型读、写与写者优先、raw trait 与契约
⑥MSRV 1.95，三个 crate 都是 edition 2024（0.12.5 是 1.71 / 2021；中间 #499 先升到 1.84）#533 中的 6020fd1、fb18e4e；#499 中的 7a9e143老工具链无法升级—
⑦其他 API：Condvar 搬进 lock_api，成为泛型 Condvar + RawCondvar（自定义 raw condvar 允许虚假唤醒，parking_lot::Condvar 仍保证不虚假唤醒）；into_inner_with_raw；Once::new_completed 与 is_completed / wait / wait_force；删除 lock_api 的 const_new 与 parking_lot 的 const_mutex 等 const_* 函数（new 本身就是 const fn）；删除空的 lock_api/nightly feature；is_locked 改为必须实现；MappedRwLockReadGuard::try_map_or_else 改名 try_map_or_err#523、#524、#520、#533（33af4d0、774d1c2、bb2d12a、9929a69 等）const_mutex(...) 等调用要改成 Mutex::new(...)Condvar、Once、外壳与守卫
⑧平台：Apple 上的超时等待不再受墙上时钟影响；32 位 Linux 的 futex 超时 ABI；ESP-IDF 的时钟；WASI 走 pthread 后端；L4Re 能编译；generic parker 不再忙等#533 中的 c175220、43d5007、3a21d7f、4a3656f；#538；#549只影响对应平台；本机（macOS）上的超时语义变了ThreadParker 的各平台实现
⑨SpinWait 的计数：前三轮自旋次数从 2 / 4 / 8 改成 1 / 2 / 4#540（合并 46b4f58），提交 7d52c89「core: fix SpinWait spin counts starting at 2 instead of 1」自旋时间略短SpinWait
⑩契约与文档：「Parking-lot operations in parking_lot_core are now guaranteed to never unwind.」；「Documented that parking-lot-based synchronization primitives must not be used internally by global allocators.」；raw lock 的安全要求补写了 acquire / release、移动已上锁的锁、unwind 等条款#533 中的 990f61e、a2486e9、874555e、90dca0b；#544写全局分配器的人不能在里面用 parking_lot 的锁park 与四种 unpark、raw trait 与契约

#533 里另有一组修复（unlock_upgradable_fair 不交接、条件等待超时不复查谓词等），以及几项涉及内存序、守卫 Send / Sync 约束和死锁检测的修复，都列在 去掉的与修正的。

两章：

  1. 延后唤醒与守卫状态：#545 改了哪几行、为什么竞争下更快；无竞争路径的反汇编对照；#544 的新 trait 签名与自定义锁的迁移要点。
  2. 去掉的与修正的：最终公平、HLE、read_recursive 去掉后各自的替代；#533 修复清单逐条对应到 0.12.5 的代码位置。

本部分的实验

#目录看什么章
—v013-asm/同一个二进制里依赖 0.12.5 和 0.13.0（都不开 deadlock_detection），反汇编 lock + 加一 + unlock 的快路径；单线程 ns/op 作旁证；反向：给 0.12.5 打开 deadlock_detectionearly-unlock
E2mutex-throughput/、v013-mutex-throughput/0.12.5 / std / 0.13.0 的竞争吞吐：锁外不做事时 0.13.0 在 T=12 快约 2.1 倍、T=4 快约 1.4 倍，锁外 200 ns 时只快约 9%；完整表与尾延迟在 和 std Mutex 比early-unlock
E3eventual-fairness/、v013-eventual-fairness/2 线程长临界区下的最长连续独占：0.12.5 约 1 ms 封顶、持锁 ≥ 1 ms 时严格交替，0.13.0 可整轮独占；完整表在 公平解锁、bump 与 FairMutexremoved-and-fixed

💬 关联讨论

发起讨论
加载中...