IO模型学习

1. 阻塞和非阻塞IO

低速系统调用是可能会使进程永远阻塞的一类系统调用：

如果某些文件类型的数据并不存在，读操作可能会使调用者永远阻塞；

如果数据不能被相同的文件类型立即接受，写操作可能会使调用者永远阻塞；

在某种条件发生之前打开某些文件类型可能会发生阻塞；

对已经加上强制性记录锁的文件进行读写；

某些ioctl操作；

某些进程间通信函数。

非阻塞IO使得我们可以发出open、read和write这样的IO操作，并使得这些操作不会永远阻塞；如果这种操作不能完成，则调用立即出错返回，表示该操作如继续执行将阻塞；

即阻塞需要等待IO结束再返回，而非阻塞可以直接返回，返回是否出错，或者可以通过轮询的方式来判断是否IO完成；

2. IO多路转接

i. select函数（异步通知）

在所有POSIX兼容的平台上，select函数使我们可以执行IO多路转接。

#include <sys/select.h>

int select(int maxfdpl, fd_set *restrict readfds,
           fd_set *restrict writefds, fd_set *restrict exceptfds,
           struct timeval *restrict tvptr);

返回值：准备就绪的描述符数目；若超时则返回0，出错返回-1；

参数：
1.readfds、writefds、exceptfds：指向描述符集的指针，说明了我们关心的可读、可写或处于异常条件的描述符集，存储于fs_set的数据类型中；
2.tvptr：愿意等待的时间长度，单位为秒或微秒；
3.maxfdp1：最大文件描述符加一；

对于一个正返回值的select调用，表示已经准备好的描述符数目，该值是3个描述符集中已准备好的描述符数之和，如果同一个描述符已经准备好了读和写，那么在返回值中会对其计两次数；对于准备好的具体说明：

readfds：某描述符进行read操作不会阻塞，则该描述符是准备好的；

writedfs: 某描述符进行write操作不会阻塞，则该描述符是准备好的；

exceptfds：某描述符中有一个未决异常条件，则该描述符是准备好的；

ii. poll（异步通知）

poll函数类似于select，但是程序员接口有所不同。

#include <poll.h>

int poll(strcut pollfd fdarray[], nfds_t nfds, int timeout);

与select不同，poll不是为每个条件构造一个描述符集，而是构造一个pollfd结构的数组，每个数组元素指定一个描述符编号以及我们对该描述符感兴趣的条件。

参数：

struct pollfd {
  int fd;
  short events;
  short revents;
};

events成员指定了我们对该描述符感兴趣的条件，由用户设置。可以为下列常量的一个或者几个：

POLLIN：可以不阻塞地读取高优先级数据以外的数据（等价于POLLRDNORM|POLLRDBAND）

POLLRDNORM：可以不阻塞地读取普通数据

POLLRDBAND：可以不阻塞地读取优先级数据

POLLPRI：可以不阻塞地读取高优先级数据

POLLOUT：可以不阻塞地写普通数据

POLLWRNORM：与POLLOUT相同

POLLWRBAND:可以不阻塞地写优先级数据

返回时，revents成员由内核设置，用于说明每个描述符发生了哪些时间；

返回值：准备就绪的描述符数目；若超时则返回0，出错返回-1；

iii. select和poll的缺点

select缺点：

1.单个进程能够监视的文件描述符的数量存在最大限制，通常是1024，当然可以更改数量，但由于select采用轮询的方式扫描文件描述符，文件描述符数量越多，性能越差；(在linux内核头文件中，有这样的定义：#define __FD_SETSIZE 1024)
2.内核 / 用户空间内存拷贝问题，select需要复制大量的句柄数据结构，产生巨大的开销；
3.select返回的是含有整个句柄的数组，应用程序需要遍历整个数组才能发现哪些句柄发生了事件；
4.select的触发方式是水平触发，应用程序如果没有完成对一个已经就绪的文件描述符进行IO操作，那么之后每次select调用还是会将这些文件描述符通知进程。

相比select模型，poll使用链表保存文件描述符，因此没有了监视文件数量的限制，但其他三个缺点依然存在。

拿select模型为例，假设我们的服务器需要支持100万的并发连接，则在__FD_SETSIZE 为1024的情况下，则我们至少需要开辟1k个进程才能实现100万的并发连接。除了进程间上下文切换的时间消耗外，从内核/用户空间大量的无脑内存拷贝、数组轮询等，是系统难以承受的。因此，基于select模型的服务器程序，要达到10万级别的并发访问，是一个很难完成的任务。

iv. epoll

设想一下如下场景：有100万个客户端同时与一个服务器进程保持着TCP连接。而每一时刻，通常只有几百上千个TCP连接是活跃的(事实上大部分场景都是这种情况)。如何实现这样的高并发？
在select/poll时代，服务器进程每次都把这100万个连接告诉操作系统(从用户态复制句柄数据结构到内核态)，让操作系统内核去查询这些套接字上是否有事件发生，轮询完后，再将句柄数据复制到用户态，让服务器应用程序轮询处理已发生的网络事件，这一过程资源消耗较大，因此，select/poll一般只能处理几千的并发连接。

调用过程

epoll的设计和实现与select完全不同。epoll通过在Linux内核中申请一个简易的文件系统(文件系统一般用什么数据结构实现？红黑树)。把原先的select/poll调用分成了3个部分：

1）调用epoll_create()建立一个epoll对象(在epoll文件系统中为这个句柄对象分配资源)
2）调用epoll_ctl向epoll对象中添加这100万个连接的套接字
3）调用epoll_wait收集发生的事件的连接

如此一来，要实现上面说是的场景，只需要在进程启动时建立一个epoll对象，然后在需要的时候向这个epoll对象中添加或者删除连接。同时，epoll_wait的效率也非常高，因为调用epoll_wait时，并没有一股脑的向操作系统复制这100万个连接的句柄数据，内核也不需要去遍历全部的连接。

实现思路

当某一进程调用epoll_create方法时，Linux内核会创建一个eventpoll结构体，这个结构体中有两个成员与epoll的使用方式密切相关。eventpoll结构体如下所示：

struct eventpoll{
    ....
    /*红黑树的根节点，这颗树中存储着所有添加到epoll中的需要监控的事件*/
    struct rb_root  rbr;
    /*双链表中则存放着将要通过epoll_wait返回给用户的满足条件的事件*/
    struct list_head rdlist;
    ....
};

每一个epoll对象都有一个独立的eventpoll结构体，用于存放通过epoll_ctl方法向epoll对象中添加进来的事件。这些事件都会挂载在红黑树中，如此，重复添加的事件就可以通过红黑树而高效的识别出来(红黑树的插入时间效率是lgn，其中n为树的高度)。

而所有添加到epoll中的事件都会与设备(网卡)驱动程序建立回调关系，也就是说，当相应的事件发生时会调用这个回调方法。这个回调方法在内核中叫ep_poll_callback,它会将发生的事件添加到rdlist双链表中。

在epoll中，对于每一个事件，都会建立一个epitem结构体，如下所示：

struct epitem{
    struct rb_node  rbn;//红黑树节点
    struct list_head    rdlink;//双向链表节点
    struct epoll_filefd  ffd;  //事件句柄信息
    struct eventpoll *ep;    //指向其所属的eventpoll对象
    struct epoll_event event; //期待发生的事件类型
}

当调用epoll_wait检查是否有事件发生时，只需要检查eventpoll对象中的rdlist双链表中是否有epitem元素即可。如果rdlist不为空，则把发生的事件复制到用户态，同时将事件数量返回给用户。

posted @ 2022-03-15 13:06 fwx 阅读(49) 评论(0) 收藏举报

刷新页面返回顶部

fwx