select,poll,epoll,IO多路复用进化史

  IO多路复用中的 “多路” 指的是同时监听多个打开文件(socket或者其他文件设备),“复用” 指的是复用一个 进程/线程 去监听这些打开文件

1.最早期的select

  伪代码表示:

 

    while (true) {
        for (fd : 监听的fd) {
          if (poll(设备)){
          返回就绪数 + 1;
  
break;   } }
     
if (返回就绪数 > 0) {
         free_wait();
break; } else {     sleep();   } }

free_wait 是从所有设备的等待队列中移除当前进程,在等待队列中的每个节点是 wait_queue_t 结构体的内存实例

当 设备就绪的时候,对设备的 poll 函数调用 会返回 true

假如要监听的文件数是 N,那么每次都要去都要去轮询所有的 设备,而不是轮询到一个就绪就停下来,因为要去计数有多少个就绪了

在就绪数量 > 0 的时候,又要调用 free_wait 去遍历所有要监听文件的 等待队列,如此一来,并且下一次调用 select 的时候,也要重复上述流程。

导致 select 每次调用的 时间复杂度是 O(N)

2. poll

  poll 和 select 一样,也是去轮询,时间复杂度也是 O (N) , 但是 poll 的监听对象不是用数组存储的,而是以链表存储的,一般select只支持监听 1024 个打开文件

  但是 poll 只要内存充足,就能监听远不止 1024 个打开文件

3. epoll

  select 和 poll 之所以低效,是因为每次的轮询,轮询到的大部分打开文件,可能都是未就绪状态

epoll 做的优化思路清晰,只把就绪的打开文件返回给 用户空间。具体的做法是 通过 epoll_create 创建 epollevent ,epollevent 内维护两个重要的数据结构:

  1.一颗便于查找的红黑树,红黑树的节点是待监听的打开文件号 + 待监听事件(其他内容省略)(rbr)

  2.一条便于增删改的双向链表,节点和上面一样,是打开文件号 + 待监听事件(其他内容省略),代表就绪的打开文件号 (rdlist)

      

  通过 epoll_ctl 添加 打开文件号 + 待监听事件 的时候,会把打开文件号 + 待监听事件打包成一个节点(epoll_item), 并且加入到上述的红黑树 和 双向链表中

  同时 创建一个 epoll_entry ,这种数据结构中有成员 wait_queue_t , wait_queue_t 就是设备的等待队列上节点的类型

   

 

  把epoll_entry 的 wait_queue_t 做为一个节点链入到 设备的等待队列中去,并且设置回调函数

  等待设备就绪的时候,驱动程序会清空等待队列,清空的方法是把等待队列的节点移除并且调用节点的回调函数

  这里的回调函数是直接唤醒 epollevent 的 wq 上等待的进程,调用 epoll_wait 的进程会被加入到 wq 上 

    

  最后,就是调用 epoll_wait 等待打开文件就绪

  值得提问的是,是不是每次一个设备就绪,就唤醒进程,那不是经常因为一个设备就被唤醒?确实可能,但是在唤醒期间,如果有多个其他设备就绪,他们也会把自己的打开文件号放到 rdlist 上

  那不会出现并发冲突吗?比如进程刚好被唤醒去拿 就绪队列上的节点,复制到自己传入的参数events数组(存储就绪的文件打开号和事件)上,并且清空就绪队列,这时候其他就绪设备把自己挂到就绪队列了怎么办?

  复制 - 清空 的过程有 eventpoll 的 mutex 互斥量 保证并发安全,不用担心。

  如果正好 复制 - 清空的时候,有新的就绪设备要将自己挂到就绪队列的话,没挂上就被阻塞。等待复制-清空完成再把自己挂上去。

  下一次 epoll_wait 的时候,因为就绪队列上有节点,所以直接 复制-清空 后返回,不阻塞

  

 

 

 

 

posted @ 2020-11-17 17:47  执生  阅读(27)  评论(0编辑  收藏