不再安全的 OSSpinLock
昨天有位开发者在Github上给我提了一个issue，里面指出OSSpinLock在新版iOS中已经不能再保证安全了，并提供了几个相关资料的链接。我仔细查了一下相关资料，确认了这个让人不爽的bug。OSSpinLock的问题
2015-12-14那天，swift-dev邮件列表里有人在讨论weak属性的线程安全问题，其中有几位苹果工程师透露了自旋锁的 bug，对话内容大致如下：
新版iOS中，系统维护了5个不同的线程优先级/QoS: background，utility，default，user-initiated，user-interactive。高优先级线程始终会在低优先级线程前执行，一个线程不会受到比它更低优先级线程的干扰。这种线程调度算法会产生潜在的优先级反转问题，从而破坏了spin lock。
具体来说，如果一个低优先级的线程获得锁并访问共享资源，这时一个高优先级的线程也尝试获得这个锁，它会处于spin lock的忙等状态从而占用大量CPU。此时低优先级线程无法与高优先级线程争夺CPU时间，从而导致任务迟迟完不成、无法释放lock。这并不只是理论上的问题，libobjc已经遇到了很多次这个问题了，于是苹果的工程师停用了OSSpinLock。
苹果工程师Greg Parker提到，对于这个问题，一种解决方案是用truly unbounded backoff算法，这能避免livelock问题，但如果系统负载高时，它仍有可能将高优先级的线程阻塞数十秒之久；另一种方案是使用handoff lock算法，这也是libobjc目前正在使用的。锁的持有者会把线程ID保存到锁内部，锁的等待者会临时贡献出它的优先级来避免优先级反转的问题。理论上这种模式会在比较复杂的多锁条件下产生问题，但实践上目前还一切都好。
libobjc里用的是Mach内核的thread_switch()然后传递了一个mach thread port来避免优先级反转，另外它还用了一个私有的参数选项，所以开发者无法自己实现这个锁。另一方面，由于二进制兼容问题，OSSpinLock也不能有改动。
最终的结论就是，除非开发者能保证访问锁的线程全部都处于同一优先级，否则iOS系统中所有类型的自旋锁都不能再使用了。
OSSpinLock 的替代方案
为了找到一个替代方案，我做了一个简单的性能测试，对比了一下几种能够替代OSSpinLock锁的性能。测试是在iPhone6、iOS9上跑的，代码在这里。这里只是测试了单线程的情况，不能反映多线程下的实际性能，所以这个结果只能当作一个定性分析
可以看到除了OSSpinLock外，dispatch_semaphore和pthread_mutex性能是最高的。有消息称，苹果在新系统中已经优化了pthread_mutex的性能，所以它看上去和OSSpinLock差距并没有那么大了。
社区反应
苹果
查看 CoreFoundation 的源码能够发现，苹果至少在2014年就发现了这个问题，并把CoreFoundation中的spinlock替换成了pthread_mutex，具体变化可以查看这两个文件：CFInternal.h(855.17)、CFInternal.h(1151.16)。苹果自己发现问题后，并没有及时更新OSSpinLock的文档，也没有告知开发者，这有些让人失望。
在 iOS 10/macOS 10.12 发布时，苹果提供了新的os_unfair_lock 作为 OSSpinLock 的替代，并且将 OSSpinLock 标记为了 Deprecated。
google/protobuf内部的spinlock 被全部替换为dispatch_semaphore，详情可以看这个提交：https://github.com/google/protobuf/pull/1060。用dispatch_semaphore 而不用pthread_mutex 应该是出于性能考虑。
相关链接
https://blog.csdn.net/fishmai/article/details/119793819
https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20151214/000344.html
http://mjtsai.com/blog/2015/12/16/osspinlock-is-unsafe/
http://engineering.postmates.com/Spinlocks-Considered-Harmful-On-iOS/
https://twitter.com/steipete/status/676851647042203648
页:
[1]