本文Demo的完整工程代码, 参考这里的GCDDemo
目录
引言
GCD是iOS开发中一个"老生常谈"的话题了, 例如之前的几篇文章
但是最近在阅读SDWebImage源码时(详见iOS开发 之 SDWebImage源码分析), 还是遇到了不知道的GCD
它就是本文的主角: barrier GCD, 即dispatch_barrier_sync和dispatch_barrier_async这两个接口
折腾了好久, 总算弄明白sync与async, serial queue与concurrent queue, 怎么又来了个barrier, 到底什么玩意?
不急, 下面我们就来一探究竟
回顾
在讨论barrier之前, 我们有必要再对GCD做一个简单的回顾
GCD的queue分为serial queue和concurrent queue两种, 其中系统为我们创建的serial queue通过dispatch_get_main_queue来获取, concurrent queue通过dispatch_get_global_queue来获取
GCD的queue与thread并无直接映射关系, async的block可能在子线程也有可能在ui thread中执行(详见iOS开发 之 Queue和Thread), 这也是GCD的价值所在, 让开发者关注队列而非线程
GCD的async接口, 将block添加到queue后会立即返回, 而sync接口与async正好相反, 将block添加到queue后直到block执行结束后才返回
在当前线程中调用sync接口, 会引起死锁(详见iOS开发 之 Queue和Thread)
barrier GCD
首先我们来看下什么是barrier GCD, Apple Documentation对dispatch_barrier_async的解释如下
Calls to this function always return immediately after the block has been submitted and never wait for the block to be invoked. When the barrier block reaches the front of a private concurrent queue, it is not executed immediately. Instead, the queue waits until its currently executing blocks finish executing. At that point, the barrier block executes by itself. Any blocks submitted after the barrier block are not executed until the barrier block completes.
The queue you specify should be a concurrent queue that you create yourself using the dispatch_queue_create function. If the queue you pass to this function is a serial queue or one of the global concurrent queues, this function behaves like the dispatch_async function.
dispatch_barrier_sync和dispatch_barrier_async其实是类似的(除了sync与async的区别), 所以本文重点讨论其中的一个接口
很多文章对官方解释做了详尽的翻译(例如可以参考Dispatch_barrier_async的研究), 而我更习惯于提炼其中的几个要点如下
通过dispatch_barrier_async添加的block会等到之前添加所有的block执行完毕再执行
在dispatch_barrier_async之后添加的block会等到dispatch_barrier_async添加的block执行完毕再执行
dispatch_barrier_async的上述特点只在自己创建的concurrent queue有效, 在serial queue和global concurrent queues中的作用和dispatch_sync完全相同
虽说是要点, 但是怎么感觉还是有点绕啊, 没关系, 重点来了
请问barrier的含义是? 没错, 这个确实是重点
barrier: 障碍物, 屏障, 界线
知道了barrier的含义, 理解dispatch_barrier_async就变得很轻松了:
以barrier为分界, 前面的执行完才能执行后面的
例子
概念介绍完了, 如果你还没理解的话, 也没关系, 我们来看下面的例子
- (IBAction)buttonOnClicked:(UIButton *)sender {
dispatch_queue_t queue = dispatch_queue_create("My concurrent queue", DISPATCH_QUEUE_CONCURRENT);
dispatch_suspend(queue);
// Enqueue five blocks
for (int index = 0; index < 5; ++index) {
dispatch_async(queue, ^{
[self printNumber:index];
});
}
// Enqueue a barrier
dispatch_barrier_async(queue, ^{
NSLog(@"--- This is a barrier ---");
});
// Enqueue five more blocks
for (int index = 5; index < 10; ++index) {
dispatch_async(queue, ^{
[self printNumber:index];
});
}
dispatch_resume(queue);
}
打印结果如下
// 此处简略描述: 一共50行, 打印0到5之间(0, 1, 2, 3, 4)的数字
--- This is a barrier ---
// 此处简略描述: 一共50行, 打印5到10之间(5, 6, 7, 8, 9)的数字
再参照上一节描述的概念, 相信你这下肯定能理解barrier的含义了
应用
说了这么多, 解释的也够清楚了, 但是为什么要有barrier GCD这两个接口呢? 它们有哪些应用呢?
从上面的例子, 其实已经可以看出些"端倪", 那就是用barrier实现: 读-写锁
读-写锁有以下几个特点
在没有写操作的时候, 可以任意的并发读取
在所有读操作完成后, 才进行写操作, 但是写操作不可以并发, 且在写操作过程中, 不能读取
在写操作完成后, 又可以任意的并发读取了
如果我们使用barrier GCD接口来处理写操作, 使用普通的GCD接口来并发读取, 那么完全满足读-写锁的以上特点
废话说到这, 最后来看例子吧
static NSString *he = @"Luke";
static NSString *she = @"Megan";
@interface ViewController ()
@property (nonatomic, strong) dispatch_queue_t queue;
@end
@implementation ViewController
- (IBAction)button1OnClicked:(UIButton *)sender {
self.queue = dispatch_queue_create("Reader-writer queue", DISPATCH_QUEUE_CONCURRENT);
for (int index = 0; index < 5; ++index) {
dispatch_async(self.queue, ^{
[self printAndRepeat];
});
}
dispatch_after(dispatch_time(DISPATCH_TIME_NOW, (int64_t)(5 * NSEC_PER_SEC)), dispatch_get_main_queue(), ^{
dispatch_barrier_async(self.queue, ^{
he = @"Don";
she = @"Alice";
});
});
}
- (void)printAndRepeat {
NSLog(@"%@ likes %@!", he, she);
dispatch_after(dispatch_time(DISPATCH_TIME_NOW, (int64_t)(1 * NSEC_PER_SEC)), dispatch_get_main_queue(), ^{
[self printAndRepeat];
});
}
@end
打印结果如下
Luke likes Megan!
Luke likes Megan!
......
// 过了5秒后
Don likes Alice!
Don likes Alice!
......
参考
更多文章, 请支持我的个人博客
