GCD 并发队列

466 查看

本篇文章由我们团队的郭杰童鞋翻译完成。这是关于GCD系列的第三篇文章,原文是GCD Concurrent Queues


如果说串行队列是互斥量更好的替代品的话,那么并发队列就是线程的一个更好的替代品。

并发队列可以让你入队的block且并发执行,而不需要等待前面入队的block完成运行。

多次运行以下程序:

dispatch_async()告诉GCD来入队block块,而不是等到block块移动之前完成。这就使我们能够快速的将5个block置于我们刚刚创建的并发队列中。

当第一个block块入队时,队列是空的,因此如果当前队列是串行,它会按照同样的方式来运行。但是,当第二个block被入队时,即使第一个block还没有运行完成,第二个也依然会运行。当然了,这种方式也同样适用于第三个、第四和第五个block,它们都会在同一时间开始运行。

队列上的每一个block在创建时会捕获index索引值, 并会打印10次记录。这个程序的输出符合您的预期吗?为什么每次运行程序的输出结果都是不一样的呢?

如果我们使用串行队列的话,程序的输出会有什么不同呢?尝试将DISPATCH_QUEUE_CONCURRENT修改为DISPATCH_QUEUE_SERIAL,然后再次运行程序,试试看。

用队列,不用线程

你可能已经错过了线程,但是上面的程序在不使用pthread_create()NSThread的情况下,毫不费力地创建并执行五个线程。由于在并发队列中每一个block都必须是同时运行的,GCD会自动创建(或征用)一个线程来运行它们中的每一个。每个block一旦完成,该线程会被摧毁或者返回到一个线程池中。使用GCD,你可以专注于队列,并让有关线程库去考虑线程问题。

虽然你不用手动管理线程,但这并不意味着你可以忽视线程的限制。如果入队的并发block比可用的线程更多,你的程序可能会出问题。

障碍(Barriers)

在这个点上的一个很自然的问题是:如果并发队列允许所有的block执行,那么为什么它们被称为”队列“呢?它不是更像一个可以加入并发执行block的堆吗?

当你考虑障碍时,并发队列的行为看起来就像队列了。使用dispatch_barrier_sync()或者dispatch_barrier_async()入队的block会带来一些有意思的事情:这个block块将会被入队,但是会等到所有的之前入队的block执行完成后才开始执行。除此之外,在barrier block后面入队的所有的block,会等到到barrier block本身已经执行完成之后才继续执行。barrier block通常被看作是一系列的并发操作集合中的”choke points”(咽喉要道)。

为了展示障碍block,看看下面的程序:

运行这个程序。可以注意到barrier之前的那些block,只有索引为0到4的block是被允许执行到完成,而在这个barrier之后,仅仅序号为5到9的block会被执行。然而,在barrier两边,每组5个block块被允许在同一个时间执行。

读写锁

在我上一篇博客中,我讲了如何使用串行队列去保护一组状态变量。使用这个技术,仅有一个线程可以在一个时间内访问一个变量,从而保证了原子行为。

但是说实话,我们没有必要在读取数据时去保护这些数据:我们仅仅需要在异步修改时去保护它们。允许多个线程读取数据而不改变数据从某些角度(如性能)来说是非常好的。

我们需要的是一个读写锁,即写入的时候串行化访问操作,但是允许多个读操作并发。

我们可以使用异步队列和barrier轻松实现一个读写锁。如下所示:

你现在可以忽略调用dispatch_after(),它只是简单的告诉GCD在一段时间后入队一个block。

在这个例子当中,barrier block是保证了修改操作的原子性。因为barrier block总是不间断的运行,你将不会看到有“Luke like Alice!”打印出来。

恭喜你!你已经了解了关于并发队列的所有内容,以及它们是怎样被用来代替线程的并创建有效的读写锁。在下一篇文章中,我们将解析全局并发队列和目标队列。下次见!