GUI线程的异步并行设计

话说,GUI的异步处理确实是个难题。真实环境的异步除了不阻塞主线程刷新,更重要的是界面上常常有很多互斥的操作,需要对线程做更为细致的控制。

原文连接 http://www.parallellabs.com/2013/01/21/multicore-and-asynchronous-communication/


GUI线程的异步并行设计

GUI线程是采用异步并行设计来提高响应度的一个经典例子。一个GUI程序的典型结构是使用一个循环来处理诸如用户点击了某个按钮、系统产生了一个中断等事件。许多GUI系统还提供了诸如优先级队列等数据结构以保证优先级高的事件能得到及时的相应。下例是一个典型的GUI系统伪代码:

01
02
03
04
05
06
07
08
09
10
while ( message = queue.receive() ) {
   if ( it is a "保存文件" request ) {
     save_document(); // 这是一个会产生阻塞的同步调用
   }
   else if ( it's a "打印文档" request ) {
     print_document(); // 这是一个会产生阻塞的同步调用
   }
else
   ...
}

这个程序有一个非常常见的性能bug:它对save_document()和print_document()这两个非常耗时的操作采用了同步调用的方式,这与GUI线程应该具备及时响应的设计初衷产生了直接矛盾。GUI线程的设计目标不仅仅是对相应的事件作出正确的响应,更重要的是这些响应必须非常及时。按照上面这个程序的逻辑,很可能会出现如下情况:用户在点击“保存文件”按钮之后,程序需要花费几秒钟才能完成save_document()调用,因此该程序在这几秒钟时间内都不能再对其他任何事件作出响应;而这时如果用户还想要调整窗口大小,这个操作在几秒钟之内都得不到响应,从而破坏用户体验。

一般来说,需要拥有高响应度的线程不应该直接执行可能带来延迟或阻塞的操作。可能带来延迟或阻塞的操作不仅仅包括保存文件、打印文件,还包括请求互斥锁、等待其他线程某个操作的完成等。

我们有三种方式来将耗时的操作从需要保持高响应度的线程中转移出去。下面让我们继续用GUI系统的例子来对这三种方法一一进行介绍,以分析它们各自适用的场景。

方式一:一个专用的工作线程

第一种将耗时操作从GUI线程中转移出去的方式是,使用一个专门的工作线程来异步地处理GUI线程发送的耗时操作请求。如下图所示,GUI线程依次将打印文档(PrintDocument)和保存文档(SaveDocument)两个异步请求发送给工作线程之后就立刻返回,从而继续对用户的其他请求做出及时的相应(例如调整窗口大小、编辑文档等);与此同时,工作线程依次对打印文档和保持文档进行顺序处理,并在并在该异步请求完成到某一进度时(或者该异步请求完成时)向GUI线程发送相应的通知信号。

图1. 使用专门的工作线程来处理GUI线程的异步请求

图1. 使用专门的工作线程来处理GUI线程的异步请求

让我们来看看这种处理方式的代码会长成什么样子:

01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
// 第一种方式:使用一个专门的工作线程来处理GUI线程的异步请求
// GUI线程:
while ( message = queue.receive() ) {
    if ( it's a "保存文档" request ) {
       worker.send( new save_msg() ); // 发送异步请求
    }
    else if ( it's a "保存文档" completion notification ) {
      display(“保存文档成功!”); // 接到异步请求的进度通知
    }
    else if ( it's a "打印文档" request ) {
       worker.send( new print_msg() ); //发送异步请求
    }
    else if ( it's a "打印文档" progress notification ) {
       if ( percent < 100 ) // 接到异步请求的进度通知
          display_print_progress( percent );
       else
          display(“打印完毕!”);
    }
    else
    ...
}
 
// 工作线程:处理来自GUI线程的异步请求
while ( message = workqueue.receive() ) {
    if ( it's a "保存文档" request )
       save_document(); // 保存文档并在结束后向GUI线程发送通知
    else if ( it's a "打印文档 " request )
       print_document(); // 打印文档并向GUI线程发送进度通知
    else
    ...
}

方式二:每一个异步请求分配一个工作线程

在第一种方法的基础之上,我们可以做一些相应的扩展:对每一个GUi线程的异步请求都分配一个专门的工作线程,而不是只用一个工作线程去处理所有异步请求。这个方式的好处很明显,异步请求被多个线程分别并行处理,因此提升了处理速度。值得注意的是,我们需要及时对这些工作线程进行垃圾回收操作,否则大量线程会造成内存资源的紧张。

图2. 为每个GUI线程的异步请求分配一个工作线程

图2. 为每个GUI线程的异步请求分配一个工作线程

这种模式的代码如下所示。因为对每个异步请求我们都启动一个新的线程,我们可以充分地利用多核的计算资源,更快地完成相应的任务。

01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
// 方式二:每一个异步请求分配一个线程
while ( message = queue.receive() ) {
    if ( it's a "保存文档" request ) {
       ...  new Thread( [] { save_dcument(); } ); // 启动新线程对异步请求进行处理
    }
    else if ( it's a "打印文档" request ) {
       new Thread( [] { print_document(); } );/ // 启动新线程对异步请求进行处理
    }
    else if ( it's a "保存文档" notification ) { ... }
                                       // 同方式一
    else if ( it's a "打印文档" progress notification ) { ... }
                                       // 同方式一
    else
       ...
}

方式三:使用线程池来处理异步请求

第三种方式更进了一步:我们可以根据多核硬件资源的多少来启动一个专门的线程池,用线程池来完成GUI线程的异步请求。这种方式的好处在于,我们可以在充分利用多核的硬件资源,以及并行地对异步请求进行高效处理间取得一个很好的平衡。该方式的工作示意图如下所示:

图3. 使用线程池来处理GUI线程的异步请求

图3. 使用线程池来处理GUI线程的异步请求

让我们来看一下这种方式的伪代码。需要注意的是,线程池的具体实现每个语言各有不同,因此下面的代码只供大家参考之用。

01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
// 方式三:使用线程池来处理异步请求
while ( message = queue.receive() ) {
if ( it's a "保存文档" request ) {
pool.run( [] { save_document(); } ); // 线程池的异步调用
}
else if ( it's a "打印文档" request ) {
pool.run( [] { print_document(); } ); //线程池的异步调用
}
else if ( it's a "保存文档" notification ) { ... }
// 同前
else if ( it's a "打印文档" progress notification ) {  ... }
// 同前
else
...
}

Grand Central Dispatch的异步并行

Grand Central Dispatch(GCD)是苹果于Mac OS X 10.6和iOS4中发布的一项并行编程技术。对使用GCD的程序员来说,只需要将需要被处理的任务块丢到一个全局的任务队列中去就可以了,这个任务队列中的任务会由操作系统自动地分配和调度多个线程来进行并行处理。将需要被处理的任务块插入到任务队列中去有两种方式:同步插入和异步插入。

让我们来看看一个使用GCD异步并行的实例。在下面的程序中,analyzeDocument函数需要完成的功能是对这个文档的字数和段落数进行相关统计。在分析一个很小的文档时,这个函数可能非常快就能执行完毕,因此在主线程中同步调用这个函数也不会有很大的性能问题。但是,如果这个文件非常的大,这个函数可能变得非常耗时,而如果仍然在主线程中同步调用该方法,就可能带来很大的性能延迟,从而影响用户体验。

01
02
03
04
05
06
07
// 不使用GCD的版本
- (IBAction)analyzeDocument:(NSButton *)sender {
     NSDictionary *stats = [myDoc analyze];
     [myModel setDict:stats];
     [myStatsView setNeedsDisplay:YES];
     [stats release];
}

使用GCD的异步并行机制来优化这个函数非常简单。如下所示,我们只需要在原来的代码基础上,先通过dispatch_get_global_queue来获取全局队列的引用,然后再将任务块通过dispatch_async方法插入该队列即可。任务块的执行会交由操作系统去处理,并在该任务块完成时通知主线程。一般来讲,异步插入的方式拥有更高的性能,因为在插入任务之后dispatch_async可以直接返回,不需要进行额外等待。

01
02
03
04
05
06
07
08
09
10
11
//使用GCD异步并行的版本
- (IBAction)analyzeDocument:(NSButton *)sender
{
dispatch_queue_t queue = dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_HIGH, 0ul);
dispatch_async(queue, ^{
          NSDictionary *stats = [myDoc analyze];
          [myModel setDict:stats];
          [myStatsView setNeedsDisplay:YES];
          [stats release];
      });
}

总结

本文对多核编程时常用的异步并行技术做了相关介绍。通过使用异步并行技术,我们可以将比较耗时的操作交给其他线程去处理,主线程因此可以去处理其他有意义的计算任务(例如相应用户的其他请求,完成其他计算任务等),从而有效提高系统的延迟性、吞吐率和响应性。


评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值