4-17.【OC】【锁】semaphore 不具备 ownership 会带来什么工程风险？在工程实践中，由于 disp

在工程实践中，由于 dispatch_semaphore（信号量）不具备 Ownership（所有权） ，它就像是一把“没有主人的锁”。这虽然提供了灵活性，但也直接导致了两个极具杀伤力的风险：优先级反转和调试极其困难。

1. 优先级反转 (Priority Inversion)

这是不具备所有权带来的最大风险。

由于信号量内部只是一个数字计数器，内核并不知道“是谁”持有了资源，只知道“谁”在等待资源。

场景：
1. 低优先级线程 (L) 获取了资源（信号量减 1）。
2. 高优先级线程 (H) 尝试获取资源，进入 wait 状态，被挂起。
3. 此时，一个中优先级线程 (M) 突然进入就绪状态。
后果： 由于内核不知道 H 在等 L，它会按照正常的调度逻辑让 M 运行。M 抢占了 L 的 CPU 时间，导致 L 迟迟无法释放信号量。结果，高优先级的 H 被中优先级的 M 变相阻塞了。
对比锁（Mutex）： 真正的锁（如 os_unfair_lock）知道锁被 L 持有。当 H 等待时，内核会触发 优先级继承（Priority Inheritance） ，临时把 L 的优先级提升到和 H 一样高，让 L 赶快跑完释放锁。

没有所有权意味着任何线程都可以调用 signal。

风险点： 在一个复杂的业务流水线中，如果代码逻辑出现 Bug，线程 B 可能会在不该释放的时候误调用了 signal。
后果： 原本被保护的临界区（加锁区域）会突然“门户大开”。两个线程可能同时进入临界区，导致数据竞争（Data Race）、内存损坏或程序崩溃。
对比锁： 锁通常会检查调用 unlock 的线程是否是之前调用 lock 的同一个线程。如果不是，系统会抛出断言或错误，帮助开发者在开发阶段就定位逻辑错误。

当你遇到死锁（Deadlock）并回溯堆栈时，所有权的有无决定了你排查问题的速度。

锁的便利性： 通过 lldb 或调试工具，你可以直接查到：“这把锁当前被线程 5 持有，而线程 2 正在等待它。”这样你就能迅速去看线程 5 在干什么。
信号量的痛苦： 信号量只记录“当前计数为 0”。你无法从信号量对象中得知到底是谁持有了资源而没有 signal。你必须肉眼检查代码中所有可能调用 signal 的地方，这在大型工程中无异于大海捞针。

由于没有所有权的约束，开发者更容易忘记成对使用 wait 和 signal。