风险评估:使用Pthread(相对于GCD或NSThread) [英] Risk Assessment: Using Pthreads (vs. GCD or NSThread)
问题描述
一位同事最近建议我使用pthreads代替GCD，因为它更快".我不同意它的速度更快，但是pthreads的风险是什么?
我的感觉是，它们最终将不会像GCD那样不受白痴的困扰(我的团队是50％的白痴). pthread很难正确吗?
GCD和pthreads都是异步进行工作的方式，但是它们有很大的不同.对GCD的大多数描述都是从线程和线程池的角度来描述它的，但是正如DrPizza所说的那样
专心于[线程和线程池]就是错了. GCD的价值不在于线程池，而在于排队.
Grand Central Dispatch for Win32:为什么我要
GCD与pthread等API相比有一些不错的好处.
-
GCD在鼓励和支持并行之海中的串行化孤岛"方面做得更多. GCD使您很容易避免很多锁和互斥锁以及条件变量，这是线程之间进行通信的常规方法.这是因为您将程序分解为任务，并且GCD处理将任务的输入和输出发送到幕后的适当线程.因此，使用GCD进行编程可以使您进行大量串行写入，而不必担心别人经常在线程代码中担心的事情.这使代码更简单，更不易出错.
-
GCD可以为您进行缩放，因此程序使用的并行度与将程序分解成的任务和硬件所允许的依赖程度一样.当然，将程序设计为可伸缩的通常比较困难，但是您仍然需要一些东西来真正利用这项工作来尽可能多地并行运行.像GCD这样的偷工作计划者可以做到这一点.
-
GCD是可组合的.如果显式地为要异步或并行执行的事情生成线程，则当您使用的库执行相同的操作时，您可能会遇到问题.假设您决定可以同时运行八个线程，因为在运行该程序的计算机上，这就是对您的程序有效的线程数.然后说您在每个线程上使用的库执行相同的操作.现在，您最多可以一次运行64个线程，这比您知道对程序有效的线程还要多.
线程池解决了这个问题，但是每个人都需要使用相同的线程池. GCD在内部使用线程池，并为每个人提供相同的池.
-
GCD提供了很多源"，可以轻松编写依赖于源或从源获取输入的事件驱动程序.例如，您可以很容易地设置一个队列，以在每次可在网络套接字上读取数据时或在计时器触发时或任何其他时间启动任务.
A colleague suggested recently that I use pthreads instead of GCD because it's, "way faster." I don't disagree that it's faster, but what's the risk with pthreads?
My feeling is that they will ultimately not be anywhere nearly as idiot-proof as GCD (and my team of one is 50% idiots). Are pthreads hard to get right?
GCD and pthreads are both ways of doing work asynchronously, but they are significantly different. Most descriptions of GCD describe it in terms of threads and of thread pooling, but as DrPizza puts it
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
GCD has some nice benefits over APIs like pthreads.
GCD does more to encourage and support "islands of serialization in a sea of parallelism." GCD makes it easy to avoid a lot of locks and mutexes and condition variables that are the normal way of comunicating between threads. This is because you decompose your program into tasks and GCD handles getting the task input and output to the appropriate thread behind the scenes. So programming with GCD allows you to pretty much write serially and not worry too much about stuff people often worry about in threaded code. That makes the code simpler and less bug prone.
GCD can do scaling for you so the program uses as much parallelism as the dependencies between the tasks you've decomposed your program into and the hardware allow for. Of course designing the program to be scalable is generally the hard bit, but you'll still need something to actually take advantage of that work to run as much as possible in parallel. Work stealing schedulers like GCD do that part.
GCD is composable. If you explicitly spawn threads for things you want to do asynchronously or in parallel you can run into a problem when libraries you use do the same thing. Say you decide you can run eight threads simultaneously because that's how many threads will be effective for your program given the machine it runs on. And then say a library you use on each thread does the same thing. Now you could have up to 64 threads running at once, which is more than you know is effective for your program.
Thread pooling solves this but everyone needs to use the same thread pool. GCD uses thread pooling internally and provides the same pool to everyone.
GCD provides a bunch of 'sources' and makes it easy to write an event driven program that depends on or takes input from the sources. For example you can very easily have a queue set up to launch a task every time data is available to read on a network socket, or when a timer fires, or whatever.
这篇关于风险评估:使用Pthread(相对于GCD或NSThread)的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
