再谈同步/异步与阻塞/非阻塞
几年前写过一篇描写同步/异步以及阻塞/非阻塞的文章,今天回头来看bug不少,于是需要重新整理一下原来的描述.
同步/异步
首先来解释同步和异步的概念,这两个概念与消息的通知机制有关.
举个例子,比如我去银行办理业务,可以自己去排队办理,也可以叫人代办,等他帮忙处理完了直接给我结果,对于要办理这个银行业务的人而言,自己去办理是同步方式,而别人代办完毕则是异步方式.区别在于,同步的方式下,操作者主动完成了这件事情.异步方式下,调用指令发出之后,操作马上就返回了,操作者并不能马上就知道结果了,而是等待所调用的异步过程(在这个例子中是帮忙代办的人)处理完毕之后,通过通知手段(在代码中通常是回调函数)来告诉操作者结果.
在上图的异步IO模型中,应用程序调用完aio_read之后,不论是否有数据可读,这个操作都会马上返回,这个过程相当于这个例子中委托另一个人去帮忙代办银行业务的过程,当数据读完拷贝到用户内存之后,会发一个信号通知原进程告诉读数据操作已经完成(而不仅仅是有数据可读).
阻塞/非阻塞
接着解释阻塞/非阻塞的概念,这两个概念与程序处理事务时的状态有关.
同样是前面的例子,当真正执行办理业务的人去办理银行业务时,前面可能已经有人排队等候了.如果这个人一直从排队到办理完毕,中间都没有做过其他的事情,那么这个过程就是阻塞的,这个人当前只在做这么一件事情.
在上图中,应用程序发起recvfrom操作之后,要等待数据拷贝成功才能返回,这一整个过程中,不能做其它的操作,这个就是典型的阻塞IO.
反之,如果这个人发现前面排队的人不少,于是选择了出去逛逛,过了一会再回来看看有没有轮到他的号被叫到,如果没有又继续出去逛过一阵再回来看看,如此以往,这个过程就是非阻塞的,因为处理这个事情的人,在这整个过程中,并没有做到除了这件事之外不能再做别的事情,他的做法是反复的过来尝试,如果没有完成就下一次再次尝试完成这件事情.
上图与前面阻塞IO图示的区别在于,当没有数据可读时,同样的recvfrom操作返回了错误码,表示当前没有可读数据,换言之,即使没有数据也不会一直让这个应用阻塞在这个调用上,这就是非阻塞IO.
到了这里,可以先简单的小结一下这两组概念了:
阻塞/非阻塞:区别在于完成一件事情时,是不是当事情还没有完成时,处理这件事情的人除此之外不能再做别的事情.
同步/异步:是自己去做这件事情,还是等别人做好了来通知你做好了,然后自己去拿结果.注意,这里说的是拿结果.如果只是别人告诉你可以做某事,然后自己去操作,这种情况下也是同步的操作,在后面多路复用I/O中会进行阐述.
可见,两组概念不是一个维度的概念.我们把需要办理银行业务的人称为A,把代办理的人称为B,那么在A委托B办理业务的情况下,假设A在交代B帮忙办事之后,A就去做别的事情了,那么A并不存在针对办理银行业务这件事情而言是阻塞还是非阻塞,办理事务时阻塞与否是针对真正需要办理这件事情的人,也就是这个例子里的B.
与多路复用I/O的联系
前几年写上一篇文章的时候,将多路复用I/O类的select/poll等和异步操作混为一谈,在这里需要特别做一些补充说明.在以前的说明中,就这个例子而言,我列举了一个情况,当去办理业务的人,需要排队时通常都会先去叫号拿到一个纸条上面写了号码,然后等待银行叫号,在那个例子里面,我将银行叫号比作select操作,把纸条比作向select注册的回调函数,一旦可以进行操作的条件满足,就会根据这个回调函数来通知办理人,然后办理人再去完成工作,因此select等多路复用操作是异步的行为.
上面那个例子,最大的错误在于,没有意识到,同步与异步的区别在于是不是要求办理者自己来完成,所有需要自己去完成操作的都是同步操作,不管是注册了一个回调(这里的叫号小纸条)等待别人回调你,还是自己一直阻塞等待.在上面的例子中,虽然对需要办理业务的人而言,通过叫号小纸条,他可以等待银行的办理通知,等待的同时可以去做点别的事情,比如看看手机什么的,但是只要可以办理该业务的条件满足,真正叫到了你的号可以办理业务时,办理者是需要自己去完成办理的.
换言之,在完成一件事情时,这里需要区分处理两种状态:一是这个事情是不是可以做了(条件满足的消息,如select告诉你某个文件描述符可读),一是完成了这件事情(如调用read/write完成IO操作).多路复用IO做的,是它可以记录下来有哪些人在等待消息的通知,在条件满足时负责通知办理者,而完成这件事情还是需要办理者自己去完成.只要是自己去完成的操作,都是同步的操作.
UNP的6.2节中,最后对异步/同步做的总结是最准确的了:
POSIX defines these two terms as follows:
A synchronous I/O operation causes the requesting process to be blocked until that I/O operation completes.
An asynchronous I/O operation does not cause the requesting process to be blocked.
Using these definitions, the first four I/O models—blocking, nonblocking, I/O multiplexing, and signal-driven I/O—are all synchronous because the actual I/O operation (recvfrom) blocks the process. Only the asynchronous I/O model matches the asynchronous I/O definition.