blog: dispatch

显示标签为“dispatch”的博文。显示所有博文

2013年4月21日星期日

Dispatch Sources

何为Dispatch Sources

　　简单来说，dispatch source是一个监视某些类型事件的对象。当这些事件发生时，它自动将一个block放入一个dispatch queue的执行例程中。说的貌似有点不清不楚。我们到底讨论哪些事件类型？
　　下面是GCD 10.6.0版本支持的事件：

[cpp]view plaincopy
Mach port send right state changes.    
Mach port receive right state changes.    
External process state change.    
File descriptor ready for read.    
File descriptor ready for write.    
Filesystem node event.    
POSIX signal.    
Custom timer.    
Custom event.   

　　这是一堆很有用的东西，它支持所有kqueue所支持的事件（kqueue是什么？见http://en.wikipedia.org/wiki/Kqueue）以及mach（mach是什么？见http://en.wikipedia.org/wiki/Mach_(kernel)）端口、内建计时器支持（这样我们就不用使用超时参数来创建自己的计时器）和用户事件。

用户事件

　　这些事件里面多数都可以从名字中看出含义，但是你可能想知道啥叫用户事件。简单地说，这种事件是由你调用dispatch_source_merge_data函数来向自己发出的信号。
　　这个名字对于一个发出事件信号的函数来说，太怪异了。这个名字的来由是GCD会在事件句柄被执行之前自动将多个事件进行联结。你可以将数据“拼接”至dispatch source中任意次，并且如果dispatch queue在这期间繁忙的话，GCD只会调用该句柄一次（不要觉得这样会有问题，看完下面的内容你就明白了）。
　　用户事件有两种： DISPATCH_SOURCE_TYPE_DATA_ADD 和 DISPATCH_SOURCE_TYPE_DATA_OR.用户事件源有个 unsigned long data属性，我们将一个 unsigned long传入 dispatch_source_merge_data。当使用 _ADD版本时，事件在联结时会把这些数字相加。当使用 _OR版本时，事件在联结时会把这些数字逻辑与运算。当事件句柄执行时，我们可以使用dispatch_source_get_data函数访问当前值，然后这个值会被重置为0。
　　让我假设一种情况。假设一些异步执行的代码会更新一个进度条。因为主线程只不过是GCD的另一个dispatch queue而已，所以我们可以将GUI更新工作push到主线程中。然而，这些事件可能会有一大堆，我们不想对GUI进行频繁而累赘的更新，理想的情况是当主线程繁忙时将所有的改变联结起来。
　　用dispatch source就完美了，使用DISPATCH_SOURCE_TYPE_DATA_ADD，我们可以将工作拼接起来，然后主线程可以知道从上一次处理完事件到现在一共发生了多少改变，然后将这一整段改变一次更新至进度条。
　　啥也不说了，上代码：

[cpp]view plaincopy
dispatch_source_t source = dispatch_source_create(DISPATCH_SOURCE_TYPE_DATA_ADD, 0, 0, dispatch_get_main_queue());   
dispatch_source_set_event_handler(source, ^{   
    [progressIndicator incrementBy:dispatch_source_get_data(source)];   
});   
dispatch_resume(source);   
   
dispatch_apply([array count], globalQueue, ^(size_t index) {   
    // do some work on data at index   
    dispatch_source_merge_data(source, 1);   
});   

　　（对于这段代码，我很想说点什么，我第一次用dispatch source时，我纠结了很久很久，真让人崩溃：Dispatch source启动时默认状态是挂起的，我们创建完毕之后得主动恢复，否则事件不会被传递，也不会被执行）
　　假设你已经将进度条的min/max值设置好了，那么这段代码就完美了。数据会被并发处理。当每一段数据完成后，会通知dispatch source并将dispatch source data加1，这样我们就认为一个单元的工作完成了。事件句柄根据已完成的工作单元来更新进度条。若主线程比较空闲并且这些工作单元进行的比较慢，那么事件句柄会在每个工作单元完成的时候被调用，实时更新。如果主线程忙于其他工作，或者工作单元完成速度很快，那么完成事件会被联结起来，导致进度条只在主线程变得可用时才被更新，并且一次将积累的改变更新至GUI。
　　现在你可能会想，听起来倒是不错，但是要是我不想让事件被联结呢？有时候你可能想让每一次信号都会引起响应，什么后台的智能玩意儿统统不要。啊。。其实很简单的，把你的思想放到禁锢的框子之外就行了。如果你想让每一个信号都得到响应，那使用dispatch_async函数不就行了。实际上，使用的dispatch source而不使用dispatch_async的唯一原因就是利用联结的优势。

内建事件

　　上面就是怎样使用用户事件，那么内建事件呢？看看下面这个例子，用GCD读取标准输入：

[cpp]view plaincopy
dispatch_queue_t globalQueue = dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0);   
dispatch_source_t stdinSource = dispatch_source_create(DISPATCH_SOURCE_TYPE_READ,   
                                                       STDIN_FILENO,   
                                                       0,   
                                                       globalQueue);   
dispatch_source_set_event_handler(stdinSource, ^{   
    char buf[1024];   
    int len = read(STDIN_FILENO, buf, sizeof(buf));   
    if(len > 0)   
        NSLog(@"Got data from stdin: %.*s", len, buf);   
});   
dispatch_resume(stdinSource);   

　　简单的要死！因为我们使用的是全局队列，句柄自动在后台执行，与程序的其他部分并行，这意味着对这种情况的提速：事件进入程序时，程序正在处理其他事务。
　　这是标准的UNIX方式来处理事务的好处，不用去写loop。如果使用经典的 read调用，我们还得万分留神，因为返回的数据可能比请求的少，还得忍受无厘头的“errors”，比如 EINTR (终端系统调用)。使用GCD，我们啥都不用管，就从这些蛋疼的情况里解脱了。如果我们在文件描述符中留下了未读取的数据，GCD会再次调用我们的句柄。
　　对于标准输入，这没什么问题，但是对于其他文件描述符，我们必须考虑在完成读写之后怎样清除描述符。对于dispatch source还处于活跃状态时，我们决不能关闭描述符。如果另一个文件描述符被创建了（可能是另一个线程创建的）并且新的描述符刚好被分配了相同的数字，那么你的dispatch source可能会在不应该的时候突然进入读写状态。de这个bug可不是什么好玩的事儿。
　　适当的清除方式是使用 dispatch_source_set_cancel_handler，并传入一个block来关闭文件描述符。然后我们使用 dispatch_source_cancel来取消dispatch source，使得句柄被调用，然后文件描述符被关闭。
　　使用其他dispatch source类型也差不多。总的来说，你提供一个source（mach port、文件描述符、进程ID等等）的区分符来作为diapatch source的句柄。mask参数通常不会被使用，但是对于 DISPATCH_SOURCE_TYPE_PROC 来说mask指的是我们想要接受哪一种进程事件。然后我们提供一个句柄，然后恢复这个source（前面我加粗字体所说的，得先恢复），搞定。dispatch source也提供一个特定于source的data，我们使用 dispatch_source_get_data函数来访问它。例如，文件描述符会给出大致可用的字节数。进程source会给出上次调用之后发生的事件的mask。具体每种source给出的data的含义，看man page吧。

计时器

　　计时器事件稍有不同。它们不使用handle/mask参数，计时器事件使用另外一个函数 dispatch_source_set_timer 来配置计时器。这个函数使用三个参数来控制计时器触发：start参数控制计时器第一次触发的时刻。参数类型是 dispatch_time_t，这是一个opaque类型，我们不能直接操作它。我们得需要 dispatch_time 和 dispatch_walltime 函数来创建它们。另外，常量 DISPATCH_TIME_NOW 和 DISPATCH_TIME_FOREVER 通常很有用。interval参数没什么好解释的。leeway参数比较有意思。这个参数告诉系统我们需要计时器触发的精准程度。所有的计时器都不会保证100%精准，这个参数用来告诉系统你希望系统保证精准的努力程度。如果你希望一个计时器没五秒触发一次，并且越准越好，那么你传递0为参数。另外，如果是一个周期性任务，比如检查email，那么你会希望每十分钟检查一次，但是不用那么精准。所以你可以传入60，告诉系统60秒的误差是可接受的。
　　这样有什么意义呢？简单来说，就是降低资源消耗。如果系统可以让cpu休息足够长的时间，并在每次醒来的时候执行一个任务集合，而不是不断的醒来睡去以执行任务，那么系统会更高效。如果传入一个比较大的leeway给你的计时器，意味着你允许系统拖延你的计时器来将计时器任务与其他任务联合起来一起执行。

总结

　　现在你知道怎样使用GCD的dispatch source功能来监视文件描述符、计时器、联结的用户事件以及其他类似的行为。由于dispatch source完全与dispatch queue相集成，所以你可以使用任意的dispatch queue。你可以将一个dispatch source的句柄在主线程中执行、在全局队列中并发执行、或者在用户队列中串行执行（执行时会将程序的其他模块的运算考虑在内）。
　　下一篇我会讨论如何对dispatch queue进行挂起、恢复、重定目标操作；如何使用dispatch semaphore；如何使用GCD的一次性初始化功能。

Dispatch Queue挂起恢复和目标指定

Dispatch Queue挂起恢复

　　dispatch queue可以被挂起和恢复。使用 dispatch_suspend函数来挂起，使用 dispatch_resume 函数来恢复。这两个函数的行为是如你所愿的。另外，这两个还是也可以用于dispatch source。
　　一个要注意的地方是，dispatch queue的挂起是block粒度的。换句话说，挂起一个queue并不会将当前正在执行的block挂起。它会允许当前执行的block执行完毕，然后后续的block不再会被执行，直至queue被恢复。
　　还有一个注意点：从man页上得来的：如果你挂起了一个queue或者source，那么销毁它之前，必须先对其进行恢复。

Dispatch Queue目标指定

　　所有的用户队列都有一个目标队列概念。从本质上讲，一个用户队列实际上是不执行任何任务的，但是它会将任务传递给它的目标队列来执行。通常，目标队列是默认优先级的全局队列。
　　用户队列的目标队列可以用函数 dispatch_set_target_queue来修改。我们可以将任意dispatch queue传递给这个函数，甚至可以是另一个用户队列，只要别构成循环就行。这个函数可以用来设定用户队列的优先级。比如我们可以将用户队列的目标队列设定为低优先级的全局队列，那么我们的用户队列中的任务都会以低优先级执行。高优先级也是一样道理。
　　有一个用途，是将用户队列的目标定为main queue。这会导致所有提交到该用户队列的block在主线程中执行。这样做来替代直接在主线程中执行代码的好处在于，我们的用户队列可以单独地被挂起和恢复，还可以被重定目标至一个全局队列，然后所有的block会变成在全局队列上执行（只要你确保你的代码离开主线程不会有问题）。
　　还有一个用途，是将一个用户队列的目标队列指定为另一个用户队列。这样做可以强制多个队列相互协调地串行执行，这样足以构建一组队列，通过挂起和暂停那个目标队列，我们可以挂起和暂停整个组。想象这样一个程序：它扫描一组目录并且加载目录中的内容。为了避免磁盘竞争，我们要确定在同一个物理磁盘上同时只有一个文件加载任务在执行。而希望可以同时从不同的物理磁盘上读取多个文件。要实现这个，我们要做的就是创建一个dispatch queue结构，该结构为磁盘结构的镜像。
　　首先，我们会扫描系统并找到各个磁盘，为每个磁盘创建一个用户队列。然后扫描文件系统，并为每个文件系统创建一个用户队列，将这些用户队列的目标队列指向合适的磁盘用户队列。最后，每个目录扫描器有自己的队列，其目标队列指向目录所在的文件系统的队列。目录扫描器枚举自己的目录并为每个文件向自己的队列提交一个block。由于整个系统的建立方式，就使得每个物理磁盘被串行访问，而多个物理磁盘被并行访问。除了队列初始化过程，我们根本不需要手动干预什么东西。

dispatch 与 IO 文件操作

磁盘文件操作在返回资源的时间上比较长，这时候cpu就会空闲。

原始程序

我们的程序只是简单地遍历~/Pictures然后生成缩略图。这个程序是个命令行程序，没有图形界面（尽管是使用Cocoa开发库的），主函数如下：

    int main(int argc, char **argv)
    {
        NSAutoreleasePool *outerPool = [NSAutoreleasePool new];
        
        NSApplicationLoad();
        
        NSString *destination = @"/tmp/imagegcd";
        [[NSFileManager defaultManager] removeItemAtPath: destination error: NULL];
        [[NSFileManager defaultManager] createDirectoryAtPath: destination
                                        withIntermediateDirectories: YES
                                        attributes: nil
                                        error: NULL];
        
        
        Start();
        
        NSString *dir = [@"~/Pictures" stringByExpandingTildeInPath];
        NSDirectoryEnumerator *enumerator = [[NSFileManager defaultManager] enumeratorAtPath: dir];
        int count = 0;
        for(NSString *path in enumerator)
        {
            NSAutoreleasePool *innerPool = [NSAutoreleasePool new];
            
            if([[[path pathExtension] lowercaseString] isEqual: @"jpg"])
            {
                path = [dir stringByAppendingPathComponent: path];
                
                NSData *data = [NSData dataWithContentsOfFile: path];
                if(data)
                {
                    NSData *thumbnailData = ThumbnailDataForData(data);
                    if(thumbnailData)
                    {
                        NSString *thumbnailName = [NSString stringWithFormat: @"%d.jpg", count++];
                        NSString *thumbnailPath = [destination stringByAppendingPathComponent: thumbnailName];
                        [thumbnailData writeToFile: thumbnailPath atomically: NO];
                    }
                }
            }
            
            [innerPool release];
        }
        
        End();
        
        [outerPool release];
    }

如果你要看到所有的副主函数的话，到文章顶部下载源代码吧。当前这个程序是imagegcd1.m。程序中重要的部分都在这里了。. Start 函数和 End 函数只是简单的计时函数（内部实现是使用的gettimeofday函数）。ThumbnailDataForData函数使用Cocoa库来加载图片数据生成Image对象，然后将图片缩小到320×320大小，最后将其编码为JPEG格式。

简单而天真的并发

乍一看，我们感觉将这个程序并发计算化，很容易。循环中的每个迭代器都可以放入GCD global queue中。我们可以使用dispatch queue来等待它们完成。为了保证每次迭代都会得到唯一的文件名数字，我们使用OSAtomicIncrement32来原子操作级别的增加count数：

    dispatch_queue_t globalQueue = dispatch_get_global_queue(0, 0);
    dispatch_group_t group = dispatch_group_create();
    __block uint32_t count = -1;
    for(NSString *path in enumerator)
    {
        dispatch_group_async(group, globalQueue, BlockWithAutoreleasePool(^{
            if([[[path pathExtension] lowercaseString] isEqual: @"jpg"])
            {
                NSString *fullPath = [dir stringByAppendingPathComponent: path];
                
                NSData *data = [NSData dataWithContentsOfFile: fullPath];
                if(data)
                {
                    NSData *thumbnailData = ThumbnailDataForData(data);
                    if(thumbnailData)
                    {
                        NSString *thumbnailName = [NSString stringWithFormat: @"%d.jpg",
                                                   OSAtomicIncrement32(&count;)];
                        NSString *thumbnailPath = [destination stringByAppendingPathComponent: thumbnailName];
                        [thumbnailData writeToFile: thumbnailPath atomically: NO];
                    }
                }
            }
        });
    }
    dispatch_group_wait(group, DISPATCH_TIME_FOREVER);

这个就是imagegcd2.m，但是，注意，别运行这个程序，有很大的问题。

如果你无视我的警告还是运行这个imagegcd2.m了，你现在很有可能是在重启了电脑后，又打开了我的页面。。如果你乖乖地没有运行这个程序的话，运行这个程序发生的情况就是（如果你有很多很多图片在~/Pictures中）：电脑没反应，好久好久都不动，假死了。。

问题在哪

问题出在哪？就在于GCD的智能上。GCD将任务放到全局线程池中运行，这个线程池的大小根据系统负载来随时改变。例如，我的电脑有四核，所以如果我使用GCD加载任务，GCD会为我每个cpu核创建一个线程，也就是四个线程。如果电脑上其他任务需要进行的话，GCD会减少线程数来使其他任务得以占用cpu资源来完成。

但是，GCD也可以增加活动线程数。它会在其他某个线程阻塞时增加活动线程数。假设现在有四个线程正在运行，突然某个线程要做一个操作，比如，读文件，这个线程就会等待磁盘响应，此时cpu核心会处于未充分利用的状态。这是GCD就会发现这个状态，然后创建另一个线程来填补这个资源浪费空缺。

现在，想想上面的程序发生了啥？主线程非常迅速地将任务不断放入global queue中。GCD以一个少量工作线程的状态开始，然后开始执行任务。这些任务执行了一些很轻量的工作后，就开始等待磁盘资源，慢得不像话的磁盘资源。

我们别忘记磁盘资源的特性，除非你使用的是SSD或者牛逼的RAID，否则磁盘资源会在竞争的时候变得异常的慢。。

刚开始的四个任务很轻松地就同时访问到了磁盘资源，然后开始等待磁盘资源返回。这时GCD发现CPU开始空闲了，它继续增加工作线程。然后，这些线程执行更多的磁盘读取任务，然后GCD再创建更多的工资线程。。。

可能在某个时间文件读取任务有完成的了。现在，线程池中可不止有四个线程，相反，有成百上千个。。。GCD又会尝试将工作线程减少（太多使用CPU资源的线程），但是减少线程是由条件的，GCD不可以将一个正在执行任务的线程杀掉，并且也不能将这样的任务暂停。它必须等待这个任务完成。所有这些情况都导致GCD无法减少工作线程数。

然后所有这上百个线程开始一个个完成了他们的磁盘读取工作。它们开始竞争CPU资源，当然CPU在处理竞争上比磁盘先进多了。问题在于，这些线程读完文件后开始编码这些图片，如果你有很多很多图片，那么你的内存将开始爆仓。。然后内存耗尽咋办？虚拟内存啊，虚拟内存是啥，磁盘资源啊。Oh shit！~

然后进入了一个恶性循环，磁盘资源竞争导致更多的线程被创建，这些线程导致更多的内存使用，然后内存爆仓导致虚拟内存交换，直至GCD创建了系统规定的线程数上限（可能是512个），而这些线程又没法被杀掉或暂停。。。

这就是使用GCD时，要注意的。GCD能智能地根据CPU情况来调整工作线程数，但是它却无法监视其他类型的资源状况。如果你的任务牵涉大量IO或者其他会导致线程block的东西，你需要把握好这个问题。

修正
问题的根源来自于磁盘IO，然后导致恶性循环。解决了磁盘资源碰撞，就解决了这个问题。

GCD的custom queue使得这个问题易于解决。Custom queue是串行的。如果我们创建一个custom queue然后将所有的文件读写任务放入这个队列，磁盘资源的同时访问数会大大降低，资源访问碰撞就避免了。

虾米是我们修正后的代码，使用IO queue（也就是我们创建的custom queue专门用来读写磁盘）：

    dispatch_queue_t globalQueue = dispatch_get_global_queue(0, 0);
    dispatch_queue_t ioQueue = dispatch_queue_create("com.mikeash.imagegcd.io", NULL);
    dispatch_group_t group = dispatch_group_create();
    __block uint32_t count = -1;
    for(NSString *path in enumerator)
    {
        if([[[path pathExtension] lowercaseString] isEqual: @"jpg"])
        {
            NSString *fullPath = [dir stringByAppendingPathComponent: path];
            
            dispatch_group_async(group, ioQueue, BlockWithAutoreleasePool(^{
                NSData *data = [NSData dataWithContentsOfFile: fullPath];
                if(data)
                    dispatch_group_async(group, globalQueue, BlockWithAutoreleasePool(^{
                        NSData *thumbnailData = ThumbnailDataForData(data);
                        if(thumbnailData)
                        {
                            NSString *thumbnailName = [NSString stringWithFormat: @"%d.jpg",
                                                       OSAtomicIncrement32(&count;)];
                            NSString *thumbnailPath = [destination stringByAppendingPathComponent: thumbnailName];
                            dispatch_group_async(group, ioQueue, BlockWithAutoreleasePool(^{
                                [thumbnailData writeToFile: thumbnailPath atomically: NO];
                            }));
                        }
                    }));
            }));
        }
    }
    dispatch_group_wait(group, DISPATCH_TIME_FOREVER);

这个就是我们的 imagegcd3.m.

GCD使得我们很容易就将任务的不同部分放入相同的队列中去（简单地嵌套一下dispatch）。这次我们的程序将会表现地很好。。。我是说多数情况。。。。

问题在于任务中的不同部分不是同步的，导致了整个程序的不稳定。我们的新程序的整个流程如下：

    Main Thread          IO Queue            Concurrent Queue
    
    find paths  ------>  read  ----------->  process
                                             ...
                         write <----------- pre="" process="">

图中的箭头是非阻塞的，并且会简单地将内存中的对象进行缓冲。

现在假设一个机器的磁盘足够快，快到比CPU处理任务（也就是图片处理）要快。其实不难想象：虽然CPU的动作很快，但是它的工作更繁重，解码、压缩、编码。从磁盘读取的数据开始填满IO queue，数据会占用内存，很可能越占越多（如果你的~/Pictures中有很多很多图片的话）。

然后你就会内存爆仓，然后开始虚拟内存交换。。。又来了。。

这就会像第一次一样导致恶性循环。一旦任何东西导致工作线程阻塞，GCD就会创建更多的线程，这个线程执行的任务又会占用内存（从磁盘读取的数据），然后又开始交换内存。。

结果：这个程序要么就是运行地很顺畅，要么就是很低效。

注意如果磁盘速度比较慢的话，这个问题依旧会出现，因为缩略图会被缓冲在内存里，不过这个问题导致的低效比较不容易出现，因为缩略图占的内存少得多。

真正的修复

由于上一次我们的尝试出现的问题在于没有同步不同部分的操作，所以让我写出同步的代码。最简单的方法就是使用信号量来限制同时执行的任务数量。

那么，我们需要限制为多少呢？

显然我们需要根据CPU的核数来限制这个量，我们又想马儿好又想马儿不吃草，我们就设置为cpu核数的两倍吧。不过这里只是简单地这样处理，GCD的作用之一就是让我们不用关心操作系统的内部信息（比如cpu数），现在又来读取cpu核数，确实不太妙。也许我们在实际应用中，可以根据其他需求来定义这个限制量。

现在我们的主循环代码就是这样了：

    dispatch_queue_t ioQueue = dispatch_queue_create("com.mikeash.imagegcd.io", NULL);
    
    int cpuCount = [[NSProcessInfo processInfo] processorCount];
    dispatch_semaphore_t jobSemaphore = dispatch_semaphore_create(cpuCount * 2);
    
    dispatch_group_t group = dispatch_group_create();
    __block uint32_t count = -1;
    for(NSString *path in enumerator)
    {
        WithAutoreleasePool(^{
            if([[[path pathExtension] lowercaseString] isEqual: @"jpg"])
            {
                NSString *fullPath = [dir stringByAppendingPathComponent: path];
                
                dispatch_semaphore_wait(jobSemaphore, DISPATCH_TIME_FOREVER);
            
                dispatch_group_async(group, ioQueue, BlockWithAutoreleasePool(^{
                    NSData *data = [NSData dataWithContentsOfFile: fullPath];
                    dispatch_group_async(group, globalQueue, BlockWithAutoreleasePool(^{
                        NSData *thumbnailData = ThumbnailDataForData(data);
                        if(thumbnailData)
                        {
                            NSString *thumbnailName = [NSString stringWithFormat: @"%d.jpg",
                                                       OSAtomicIncrement32(&count;)];
                            NSString *thumbnailPath = [destination stringByAppendingPathComponent: thumbnailName];
                            dispatch_group_async(group, ioQueue, BlockWithAutoreleasePool(^{
                                [thumbnailData writeToFile: thumbnailPath atomically: NO];
                                dispatch_semaphore_signal(jobSemaphore);
                            }));
                        }
                        else
                            dispatch_semaphore_signal(jobSemaphore);
                    }));
                }));
            }
        });
    }
    dispatch_group_wait(group, DISPATCH_TIME_FOREVER);

最终我们写出了一个能平滑运行且又快速处理的程序。

基准测试

我测试了一些运行时间，对7913张图片：

程序	处理时间 (秒)
`imagegcd1.m`	984
`imagegcd2.m`	没运行，这个还是别运行了
`imagegcd3.m`	300
`imagegcd4.m`	279

注意，因为我比较懒。所以我在运行这些测试的时候，没有关闭电脑上的其他程序。。。严格的进行对照的话，实在是太蛋疼了。。

所以这个数值我们只是参考一下。

比较有意思的是，3和4的执行状况差不多，大概是因为我电脑有15g可用内存吧。。。内存比较小的话，这个imagegcd3应该跑的很吃力，因为我发现它使用最多的时候，占用了10g内存。而4的话，没有占多少内存。

结论

GCD是个比较范特西的技术，可以办到很多事儿，但是它不能为你办所有的事儿。所以，对于进行IO操作并且可能会使用大量内存的任务，我们必须仔细斟酌。当然，即使这样，GCD还是为我们提供了简单有效的方法来进行并发计算。

dispatch

http://blog.csdn.net/kesalin/article/details/6721481

2，如何编写 block
在自动生成的工程代码中，默认打印一条语句"Hello, World!"，这个任务可以不可以用 block 语法来实现呢？答案是肯定的，请看：

[cpp]view plaincopyprint?
void (^aBlock)(void) = ^(void){ NSLog(@"Hello, World!"); };  
aBlock();  

用上面的这两行语句替换 main.m 中的 NSLog(@"Hello, World!"); 语句，编译运行，结果是一样的。

这两行语句是什么意思呢？首先，等号左边的 void (^aBlock)(void) 表示声明了一个 block，这个 block 不带参数(void)且也无返回参数(void)；等号右边的 ^(void){ } 结构表示一个 block 的实现体，至于这个 block 具体要做的事情就都在 {} 之间了。在这里我们仅仅是打印一条语句。整个语句就是声明一个 block，并对其赋值。第二个语句就是调用这个 block 做实际的事情，就像我们调用函数一样。block 很有点像 C++0X 中的 Lambda 表达式。

我们也可以这么写：

[cpp]view plaincopyprint?
void (^aBlock)(void) = 0;  
aBlock = ^(void){  
    NSLog(@" >> Hello, World!");  
};  
aBlock();  

现在我们知道了一个 block 该如何编写了，那么 block 数组呢？也很简单，请看：

[cpp]view plaincopyprint?
void (^blocks[2])(void) = {  
    ^(void){ NSLog(@" >> This is block 1!"); },  
    ^(void){ NSLog(@" >> This is block 2!"); }  
};  
  
blocks[0]();  
blocks[1]();  

谨记！
block 是分配在 stack 上的，这意味着我们必须小心里处理 block 的生命周期。
比如如下的做法是不对的，因为 stack 分配的 block 在 if 或 else 内是有效的，但是到大括号 } 退出时就可能无效了：

[cpp]view plaincopyprint?
dispatch_block_t block;  
  
if (x) {  
    block = ^{ printf("true\n"); };  
} else {  
    block = ^{ printf("false\n"); };  
}  
block();  

上面的代码就相当于下面这样的 unsafe 代码：

[cpp]view plaincopyprint?
if (x) {  
    struct Block __tmp_1 = ...; // setup details  
    block = &__tmp_1;  
} else {  
    struct Block __tmp_2 = ...; // setup details  
    block = &__tmp_2;  
}  

3，如何在 block 中修改外部变量
考虑到 block 的目的是为了支持并行编程，对于普通的 local 变量，我们就不能在 block 里面随意修改（原因很简单，block 可以被多个线程并行运行，会有问题的），而且如果你在 block 中修改普通的 local 变量，编译器也会报错。那么该如何修改外部变量呢？有两种办法，第一种是可以修改 static 全局变量；第二种是可以修改用新关键字 __block 修饰的变量。请看：

[cpp]view plaincopyprint?
__block int blockLocal  = 100;  
static int staticLocal  = 100;  
  
void (^aBlock)(void) = ^(void){   
    NSLog(@" >> Sum: %d\n", global + staticLocal);  
      
    global++;  
    blockLocal++;  
    staticLocal++;  
};  
  
aBlock();  
  
NSLog(@"After modified, global: %d, block local: %d, static local: %d\n", global, blockLocal, staticLocal);  

相似的情况，我们也可以引用 static block 或 __block block。比如我们可以用他们来实现 block 递归：

[cpp]view plaincopyprint?
// 1  
void (^aBlock)(int) = 0;  
static void (^ const staticBlock)(int) = ^(int i) {  
    if (i > 0) {  
        NSLog(@" >> static %d", i);  
        staticBlock(i - 1);  
    }  
};  
  
aBlock = staticBlock;  
aBlock(5);  
  
// 2  
__block void (^blockBlock)(int);  
blockBlock = ^(int i) {  
    if (i > 0) {  
        NSLog(@" >> block %d", i);  
        blockBlock(i - 1);  
    }  
};  
  
blockBlock(5);  

4，上面我们介绍了 block 及其基本用法，但还没有涉及并行编程。 block 与 Dispatch Queue 分发队列结合起来使用，是 iOS 中并行编程的利器。请看代码：

[cpp]view plaincopyprint?
NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];  
  
initData();  
  
// create dispatch queue  
//  
dispatch_queue_t queue = dispatch_queue_create("StudyBlocks", NULL);  
  
dispatch_async(queue, ^(void) {  
    int sum = 0;  
    for(int i = 0; i < Length; i++)  
        sum += data[i];  
      
    NSLog(@" >> Sum: %d", sum);  
      
    flag = YES;  
});  
  
// wait util work is done.  
//  
while (!flag);  
dispatch_release(queue);  
  
[pool drain];  

上面的 block 仅仅是将数组求和。首先，我们创建一个串行分发队列，然后将一个 block 任务加入到其中并行运行，这样 block 就会在新的线程中运行，直到结束返回主线程。在这里要注意 flag 的使用。flag 是 static 的，所以我们可以 block 中修改它。语句 while (!flag); 的目的是保证主线程不会 blcok 所在线程之前结束。

dispatch_queue_t 的定义如下：
typedef void (^dispatch_block_t)( void);
这意味着加入 dispatch_queue 中的 block 必须是无参数也无返回值的。

dispatch_queue_create 的定义如下：
dispatch_queue_t dispatch_queue_create(const char *label, dispatch_queue_attr_t attr);
这个函数带有两个参数：一个用于标识 dispatch_queue 的字符串；一个是保留的 dispatch_queue 属性，将其设置为 NULL 即可。

我们也可以使用
dispatch_queue_t dispatch_get_global_queue(long priority, unsigned long flags);
来获得全局的 dispatch_queue，参数 priority 表示优先级，值得注意的是：我们不能修改该函数返回的 dispatch_queue。

dispatch_async 函数的定义如下：
void dispatch_async(dispatch_queue_t queue, dispatch_block_t block);

它是将一个 block 加入一个 dispatch_queue，这个 block 会再其后得到调度时，并行运行。
相应的 dispatch_sync 函数就是同步执行了，一般很少用到。比如上面的代码如果我们修改为 dispatch_sync，那么就无需编写 flag 同步代码了。

5，dispatch_queue 的运作机制及线程间同步
我们可以将许多 blocks 用 dispatch_async 函数提交到到 dispatch_queue 串行运行。这些 blocks 是按照 FIFO(先入先出)规则调度的，也就是说，先加入的先执行，后加入的一定后执行，但在某一个时刻，可能有多个 block 同时在执行。

在上面的例子中，我们的主线程一直在轮询 flag 以便知晓 block 线程是否执行完毕，这样做的效率是很低的，严重浪费 CPU 资源。我们可以使用一些通信机制来解决这个问题，如：semaphore（信号量）。 semaphore 的原理很简单，就是生产-消费模式，必须生产一些资源才能消费，没有资源的时候，那我就啥也不干，直到资源就绪。下面来看代码：

[cpp]view plaincopyprint?
NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];  
  
initData();  
  
// Create a semaphore with 0 resource  
//  
__block dispatch_semaphore_t sem = dispatch_semaphore_create(0);  
  
// create dispatch semaphore  
//  
dispatch_queue_t queue = dispatch_queue_create("StudyBlocks", NULL);  
  
dispatch_async(queue, ^(void) {  
    int sum = 0;  
    for(int i = 0; i < Length; i++)  
        sum += data[i];  
      
    NSLog(@" >> Sum: %d", sum);  
      
    // signal the semaphore: add 1 resource  
    //  
    dispatch_semaphore_signal(sem);  
});  
  
// wait for the semaphore: wait until resource is ready.  
//  
dispatch_semaphore_wait(sem, DISPATCH_TIME_FOREVER);  
  
dispatch_release(sem);  
dispatch_release(queue);  
  
[pool drain];  

首先我们创建一个 __block semaphore，并将其资源初始值设置为 0 (不能少于 0)，在这里表示任务还没有完成，没有资源可用主线程不要做事情。然后在 block 任务完成之后，使用 dispatch_semaphore_signal 增加 semaphore 计数（可理解为资源数），表明任务完成，有资源可用主线程可以做事情了。而主线程中的 dispatch_semaphore_wait 就是减少 semaphore 的计数，如果资源数少于 0，则表明资源还可不得，我得按照FIFO（先等先得）的规则等待资源就绪，一旦资源就绪并且得到调度了，我再执行。

6 示例：
下面我们来看一个按照 FIFO 顺序执行并用 semaphore 同步的例子：先将数组求和再依次减去数组。

[cpp]view plaincopyprint?
NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];  
  
initData();  
  
__block int sum = 0;  
  
// Create a semaphore with 0 resource  
//  
__block dispatch_semaphore_t sem = dispatch_semaphore_create(0);  
__block dispatch_semaphore_t taskSem = dispatch_semaphore_create(0);  
  
// create dispatch semaphore  
//  
dispatch_queue_t queue = dispatch_queue_create("StudyBlocks", NULL);  
  
dispatch_block_t task1 = ^(void) {  
    int s = 0;  
    for (int i = 0; i < Length; i++)  
        s += data[i];  
    sum = s;  
      
    NSLog(@" >> after add: %d", sum);  
  
    dispatch_semaphore_signal(taskSem);  
};  
  
dispatch_block_t task2 = ^(void) {  
    dispatch_semaphore_wait(taskSem, DISPATCH_TIME_FOREVER);  
      
    int s = sum;  
    for (int i = 0; i < Length; i++)  
        s -= data[i];  
    sum = s;  
  
    NSLog(@" >> after subtract: %d", sum);  
    dispatch_semaphore_signal(sem);  
};  
  
dispatch_async(queue, task1);  
dispatch_async(queue, task2);  
  
// wait for the semaphore: wait until resource is ready.  
//  
dispatch_semaphore_wait(sem, DISPATCH_TIME_FOREVER);  
  
dispatch_release(taskSem);  
dispatch_release(sem);  
dispatch_release(queue);  
  
[pool drain];  

在上面的代码中，我们利用了 dispatch_queue 的 FIFO 特性，确保 task1 先于 task2 执行，而 task2 必须等待直到 task1 执行完毕才开始干正事，主线程又必须等待 task2 才能干正事。这样我们就可以保证先求和，再相减，然后再让主线程运行结束这个顺序。

7，使用 dispatch_apply 进行并发迭代：
对于上面的求和操作，我们也可以使用 dispatch_apply 来简化代码的编写：

[cpp]view plaincopyprint?
NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];  
  
initData();  
  
dispatch_queue_t queue = dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0);  
  
__block int sum = 0;  
__block int *pArray = data;  
  
// iterations  
//  
dispatch_apply(Length, queue, ^(size_t i) {  
    sum += pArray[i];  
});  
  
NSLog(@" >> sum: %d", sum);  
  
dispatch_release(queue);  
  
[pool drain];  

注意这里使用了全局 dispatch_queue。

dispatch_apply 的定义如下：
dispatch_apply(size_t iterations, dispatch_queue_t queue, void (^block)(size_t));

参数 iterations 表示迭代的次数，void (^block)(size_t) 是 block 循环体。这么做与 for 循环相比有什么好处呢？答案是：并行，这里的求和是并行的，并不是按照顺序依次执行求和的。

8, dispatch group
我们可以将完成一组相关任务的 block 添加到一个 dispatch group 中去，这样可以在 group 中所有 block 任务都完成之后，再做其他事情。比如 6 中的示例也可以使用 dispatch group 实现：

[cpp]view plaincopyprint?
NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];  
  
initData();  
  
__block int sum = 0;  
  
// Create a semaphore with 0 resource  
//  
__block dispatch_semaphore_t taskSem = dispatch_semaphore_create(0);  
  
// create dispatch semaphore  
//  
dispatch_queue_t queue = dispatch_queue_create("StudyBlocks", NULL);  
dispatch_group_t group = dispatch_group_create();  
  
dispatch_block_t task1 = ^(void) {  
    int s = 0;  
    for (int i = 0; i < Length; i++)  
        s += data[i];  
    sum = s;  
      
    NSLog(@" >> after add: %d", sum);  
      
    dispatch_semaphore_signal(taskSem);  
};  
  
dispatch_block_t task2 = ^(void) {  
    dispatch_semaphore_wait(taskSem, DISPATCH_TIME_FOREVER);  
      
    int s = sum;  
    for (int i = 0; i < Length; i++)  
        s -= data[i];  
    sum = s;  
      
    NSLog(@" >> after subtract: %d", sum);  
};  
  
// Fork  
dispatch_group_async(group, queue, task1);  
dispatch_group_async(group, queue, task2);  
  
// Join  
dispatch_group_wait(group, DISPATCH_TIME_FOREVER);  
  
dispatch_release(taskSem);  
dispatch_release(queue);  
dispatch_release(group);  
  
[pool drain];  

在上面的代码中，我们使用 dispatch_group_create 创建一个 dispatch_group_t，然后使用语句：dispatch_group_async(group, queue, task1); 将 block 任务加入队列中，并与组关联，这样我们就可以使用 dispatch_group_wait(group, DISPATCH_TIME_FOREVER); 来等待组中所有的 block 任务完成再继续执行。

至此我们了解了 dispatch queue 以及 block 并行编程相关基本知识，开始在项目中运用它们吧，

订阅：博文 (Atom)