GCD vs @synchronized vs NSLock

Question

有人可以简要介绍这三种系统在线程安全方面的优缺点吗？

通过观看更近期的WWDC视频,我感觉Apple正在推动使用GCD来创建线程安全的高性能读写器.

这背后有什么想法/支持？是时候访问一个必须进入内核导致这个GCD推送的锁,并回避@synchronized和NSLock？

@synchronized和NSLock是否被推出了最佳实践,或者它们仍然存在？

Answer 1

有许多细节可以在这方面进行详细讨论.但是,核心:

这些总是需要在某处或以某种方式锁定:

@synchronized(...) { ... }
[lock lock];

你提到的原因,锁是非常昂贵的; 他们必然消耗内核资源.(@synchronized()案例实际上可能会避免内核锁定,但它是一种基于散列的排除机制,而且本身也很昂贵).

而这些并不总是需要锁定(但有时可能会这样做):

dispatch_sync(...concurrent q...., ^{ ... });
dispatch_async(...queue of any kind...., ^{ ... });

调度函数有一条快速路径可以实现无锁(尽管它们将使用可能导致负载下性能问题的测试和设置原子基元).

最终结果是对并发队列的同步调度可以有效地被视为"立即在此线程上执行此操作".对串行队列的同步调度可以进行原子测试和设置以测试队列是否正在处理,将其标记为忙,如果不忙,则立即执行调用线程上的块.

异步调度可以同样快,尽管异步调度需要复制块(这可能非常便宜,但需要考虑).

一般来说,GCD可以做任何锁可以做的事情,至少可以做到 - 如果不是更多 - 有效,你可以使用GCD API超越简单锁定(使用信号量作为计算限制,用于例).

顺便说一句:如果你的任务比较粗糙,请看看NSOperationQueue和NSOperation.