关于epoll的IO模型是同步异步的一次纠结过程

这篇文章的结论就是epoll属于同步非阻塞模型，这个东西貌似目前还是有争议，在新的2.6内核之后，epoll应该属于异步io的范围了，golang的高并发特性就是底层封装了epoll模型的函数，但也有文章指出epoll属于“伪AIO”，真正的推动力实际在系统内核，另外mmap的应用加快了用户层和内核层的消息交换，对并发效率也有极大的提升。

还有一点，在DMA控制器的帮助下，实际上算是异步了，所以epoll可以说就是异步非阻塞。

《UNIX网络编程：卷一》第六章——I/O复用。书中向我们提及了5种类UNIX下可用的I/O模型：

• 阻塞式I/O；

• 非阻塞式I/O；

• I/O复用（select，poll，epoll...）；

• 信号驱动式I/O（SIGIO）；

• 异步I/O（POSIX的aio_系列函数）；

阻塞式I/O模型：默认情况下，所有套接字都是阻塞的。怎么理解？先理解这么个流程，一个输入操作通常包括两个不同阶段：

（1）等待数据准备好；

（2）从内核向进程复制数据。

对于一个套接字上的输入操作，第一步通常涉及等待数据从网络中到达。当所有等待分组到达时，它被复制到内核中的某个缓冲区。第二步就是把数据从内核缓冲区复制到应用程序缓冲区。 好，下面我们以阻塞套接字的recvfrom的的调用图来说明阻塞

<img src="https://pic2.zhimg.com/50/e83d68da03da2e8c1568b4b4b630edfd_hd.jpg" data-rawwidth="1058" data-rawheight="556" class="origin_image zh-lightbox-thumb" width="1058" data-original="https://pic2.zhimg.com/e83d68da03da2e8c1568b4b4b630edfd_r.jpg">

标红的这部分过程就是阻塞，直到阻塞结束recvfrom才能返回。

非阻塞式I/O： 以下这句话很重要：进程把一个套接字设置成非阻塞是在通知内核，当所请求的I/O操作非得把本进程投入睡眠才能完成时，不要把进程投入睡眠，而是返回一个错误。看看非阻塞的套接字的recvfrom操作如何进行

<img src="https://pic1.zhimg.com/50/4bc31cab27a9a732ab7d1ba9e674ed64_hd.jpg" data-rawwidth="1064" data-rawheight="631" class="origin_image zh-lightbox-thumb" width="1064" data-original="https://pic1.zhimg.com/4bc31cab27a9a732ab7d1ba9e674ed64_r.jpg">

可以看出recvfrom总是立即返回。

I/O多路复用：虽然I/O多路复用的函数也是阻塞的，但是其与以上两种还是有不同的，I/O多路复用是阻塞在select，epoll这样的系统调用之上，而没有阻塞在真正的I/O系统调用如recvfrom之上。如图

<img src="https://pic1.zhimg.com/50/b1ec6a4f16844a27c175d5a6a94cd7f8_hd.jpg" data-rawwidth="1136" data-rawheight="732" class="origin_image zh-lightbox-thumb" width="1136" data-original="https://pic1.zhimg.com/b1ec6a4f16844a27c175d5a6a94cd7f8_r.jpg">

信号驱动式I/O：用的很少，就不做讲解了。直接上图

<img src="https://pic1.zhimg.com/50/6294fb7f7f5c22e39187a490c35ac6f0_hd.jpg" data-rawwidth="1139" data-rawheight="711" class="origin_image zh-lightbox-thumb" width="1139" data-original="https://pic1.zhimg.com/6294fb7f7f5c22e39187a490c35ac6f0_r.jpg">

异步I/O：这类函数的工作机制是告知内核启动某个操作，并让内核在整个操作（包括将数据从内核拷贝到用户空间）完成后通知我们。如图：

<img src="https://pic2.zhimg.com/50/5819fd0fdff2bd4fdc9652291aca1831_hd.jpg" data-rawwidth="1109" data-rawheight="603" class="origin_image zh-lightbox-thumb" width="1109" data-original="https://pic2.zhimg.com/5819fd0fdff2bd4fdc9652291aca1831_r.jpg">

注意红线标记处说明在调用时就可以立马返回，等函数操作完成会通知我们。

等等，大家一定要问了，同步这个概念你怎么没涉及啊？别急，您先看总结。 其实前四种I/O模型都是同步I/O操作，他们的区别在于第一阶段，而他们的第二阶段是一样的：在数据从内核复制到应用缓冲区期间（用户空间），进程阻塞于recvfrom调用。相反，异步I/O模型在这两个阶段都要处理。

<img src="https://pic4.zhimg.com/50/8244d924a12eaf42d61b41718c559bff_hd.jpg" data-rawwidth="3200" data-rawheight="1800" class="origin_image zh-lightbox-thumb" width="3200" data-original="https://pic4.zhimg.com/8244d924a12eaf42d61b41718c559bff_r.jpg">

再看POSIX对这两个术语的定义：

• 同步I/O操作：导致请求进程阻塞，直到I/O操作完成；

• 异步I/O操作：不导致请求进程阻塞。

好，下面我用我的语言来总结一下阻塞，非阻塞，同步，异步

• 阻塞，非阻塞：进程/线程要访问的数据是否就绪，进程/线程是否需要等待；

• 同步，异步：访问数据的方式，同步需要主动读写数据，在读写数据的过程中还是会阻塞；异步只需要I/O操作完成的通知，并不主动读写数据，由操作系统内核完成数据的读写。

这是一次概念的纠结过程，对写代码没有太大意义。

过程是这样的：

首先，我的概念里往往只有同步和异步，没有太多去区别同异步IO和同异步通知两种。

另外还记得apu(2rd)中有一句“select和poll可以实现异步形式的通知”。

接着，听到了epoll是同步IO这个概念，比较意外。坚持了一下后，查到如下概念：

在unp(3rd)里的定义是：

第一是IO操作的概念：

IO操作包括：

1.等待数据准备好。

2.从内核到进程拷贝数据。

第二就是是同步IO和异步IO的区别：

同步IO导致请求进程阻塞，直到IO操作完成。

异步IO不导致请求进程阻塞。

得到的结论：

阻塞IO模型，非阻塞IO模型，IO复用模型，信号驱动IO模型都是同步IO。

epoll也是IO复用模型，应该是同步IO。

此时又意外了，再看到一个解释：

更为重要的是, epoll 因为采用 mmap的机制, 使得 内核socket buffer和 用户空间的 buffer共享, 从而省去了 socket data copy, 这也意味着, 当epoll 回调上层的 callback函数来处理 socket 数据时, 数据已经从内核层 "自动" 到了用户空间, 虽然和 用poll 一样, 用户层的代码还必须要调用 read/write, 但这个函数内部实现所触发的深度不同了.

用 poll 时, poll通知用户空间的Appliation时, 数据还在内核空间, 所以Appliation调用 read API 时, 内部会做 copy socket data from kenel space to user space.

而用 epoll 时, epoll 通知用户空间的Appliation时?, 数据已经在用户空间, 所以 Appliation调用 read API 时?, 只是读取用户空间的 buffer, 没有 kernal space和 user space的switch了.

于是想了一下：

明显没有IO操作的拷贝数据到内核空间了，stevens应该在99年就挂了，2.6内核的epoll才采用mmap机制，书籍偏旧了吧。

那么epoll是异步IO了吧。

然后再一看，你妹的，这还是不符合异步IO啊，毕竟epoll在告知OK前，是阻塞了，虽然是拷贝数据结束了。

看来好像应该修正的是IO操作定义的第二步才对，而不是那个区别。

好吧，你就暂时属于同步IO了，专心看代码，不纠结概念了。