objective-c - 风险评估 : Using Pthreads (vs. GCD 或 NSThread)

Question

一位同事最近建议我使用 pthreads 而不是 GCD，因为它“快得多”。我不同意它更快，但是 pthreads 的风险是什么？

我的感觉是，他们最终不会像 GCD 那样防白痴(我的团队中有 50% 是白痴)。 pthreads 很难搞定吗？

Answer 1

GCD 和 pthreads 都是异步工作的方式，但它们有很大的不同。大多数对 GCD 的描述都是从线程和线程池的角度来描述它的，但正如 DrPizza 所说的那样

to concentrate on [threads and thread pools] is to miss the point. GCD’s value lies not in thread pooling, but in queuing.
                                                                Grand Central Dispatch for Win32: why I want it

与 pthreads 等 API 相比，GCD 有一些不错的优势。

• GCD 更多地鼓励和支持“并行海洋中的序列化孤岛”。 GCD 可以很容易地避免大量的锁、互斥锁和条件变量，这些都是线程间通信的正常方式。这是因为您将程序分解为任务，而 GCD 处理将任务输入和输出到幕后的适当线程。因此，使用 GCD 进行编程可以让您几乎可以连续编写代码，而不必过多担心人们在线程代码中经常担心的事情。这使代码更简单，更不容易出错。

• GCD 可以为您进行缩放，因此程序使用的并行性与您将程序分解成的任务和硬件允许的任务之间的依赖性一样多。当然，将程序设计为可扩展通常是困难的一点，但您仍然需要一些东西来实际利用该工作以尽可能多地并行运行。像 GCD 这样的工作窃取调度器会做这部分工作。

• GCD 是可组合的。如果你明确地为你想异步或并行做的事情生成线程，当你使用的库做同样的事情时，你可能会遇到问题。假设您决定可以同时运行八个线程，因为在给定程序运行的机器上，这就是对您的程序有效的线程数。然后说你在每个线程上使用的库做同样的事情。现在您最多可以同时运行 64 个线程，这比您知道的对您的程序的效率要高。

  线程池解决了这个问题，但每个人都需要使用同一个线程池。 GCD 在内部使用线程池并为每个人提供相同的池。

• GCD 提供了一堆“源代码”，可以轻松编写依赖于源代码或从源代码获取输入的事件驱动程序。例如，您可以非常轻松地设置一个队列，以便在每次网络套接字上有数据可供读取时、或者当计时器触发时或其他任何时间启动任务。