如何通过调度并发队列（GCD）实现重入锁机制？

Question

我刚刚阅读了this post，它的解决方案似乎很有说服力：

• 串行队列用于同步访问
• dispatch_get_specific/dispatch_set_specific 用于提供重入能力。

我感兴趣的是是否有可能推进该方案以实现并发调度队列的重入锁定机制（每次读取使用dispatch_sync完成，写入使用dispatch_barrier_async完成，如所述here, see "One Resource, Multiple Readers, and a Single Writer")。

附：我想我已经设法使用[NSThread currentThread].threadDictionaryhere 实现了这一点，但我不喜欢处理[NSThread currentThread]，因为我依赖GCD。是否可以用一些棘手的dispatch_set_specific/dispatch_get_specific 代码替换[NSThread currentThread].threadDictionary 的用法？

Answer 1

您在对链接帖子的评论中询问我是否会对此问题发表评论。对不起，我花了这么长时间，但我记得我第一次看它的时候，我觉得我没有什么有成效的说法。但是我今天想起了这个话题，然后又遇到了这个问题，我想我会试一试：

总的来说，我建议根本不要走这条路。正如我在the linked-to/from answer 中解释的那样，使用dispatch_get/set_specific 实现递归“锁”是永远 防弹的，并且超越了@987654325 的单写/多读语义的简单串行案例@ 不会消除这些问题，而且可能会引入更多问题。

顺便说一句，如果您只是在为线程本地存储寻找[NSThread threadDictionary] 的替代品，也许是非Objective-C API 的形式，那么您应该使用pthread_setspecific 和pthread_getspecific .这些是（几乎可以肯定）构建 [NSThread threadDictionary] 的较低级别的 POSIX 调用。

退一步说：在资深系统程序员中，有一种非常强烈的观点，即递归锁从一开始就是一种反模式，应该避免。这是interesting treatise on the subject。 （如果您对 POSIX 中为什么存在递归互斥锁的杜撰故事不感兴趣，只需搜索“客观事实”即可跳转到与该问题相关的部分。）那篇文章是用更原始的“锁”编写的"（由互斥体和条件组成），这与队列有根本的不同，尽管队列可以（有时非常有用）适应在某些常见情况下模拟锁。然而，即使它们不同，如​​果你考虑一下 Butenhof 对递归原始锁的批评，很快就会发现，在递归锁的许多“坏”方面，使用队列来模拟锁更糟糕。例如，在最基本的层面上，解锁队列模拟锁的唯一方法是返回； 没有其他方法可以释放基于队列的锁。调用可能需要递归重新进入该锁的其他代码，而调用者继续持有它，这可能是“锁”被持有时间的无限延长。

一条对我很有帮助的一般建议是“使用完成工作的最高级别的抽象”。在这个问题的上下文中，这将转化为（暂时搁置上述对递归锁定的批评）：如果您在 Objective-C 中工作，并且无论出于何种原因，您想要递归锁，只需使用 @synchronized .当性能分析告诉您使用 @synchronized 实际上给您带来了问题时，然后寻找更好的解决方案（有远见地知道“更好的解决方案”可能需要远离递归锁在一起。）

总之，尝试调整 GCD 的并发队列屏障行为来模拟递归读取器/写入器锁感觉像是一个失败的提议。充其量，它总是会受到我为串行案例解释的over here 的限制。在最坏的情况下，您正在发布一种最终会降低并发性的模式。