slect,poll,epoll区别

一、select、poll、epoll三者的特点及区别

(1)select系统调用
下面是select的函数接口:
int select (int n, fd_set *readfds, fd_set *writefds, fd_set *exceptfds, struct timeval *timeout);

select创建了3个文件描述符集(fd_set)并拷贝到内核中,分别监听读、写、异常动作。
select可以监听的文件描述符受到单个进程所能打开的fd的限制,默认为1024.
采用轮询方式,遍历所有的fd,最后返回一个文件描述符是否就绪的mask掩码,并根据mask掩码给fd_set赋值。将之前的fd_set拷贝传出到用户态并返回就绪的文件描述符的总个数。
用户态并不知道是哪些文件描述符处于就绪态,需要遍历来判断。应用程序索引就绪文件描述符的时间复杂度是O(n).
再次调用select时,需要将新的fd_set监听文件描述符拷贝传入进内核。
select只能工作在相对较低下的LT模式

(2)poll系统调用

int poll (struct pollfd *fds, unsigned int nfds, int timeout);
struct pollfd {
int fd; /* file descriptor */
short events; /* requested events to watch */
short revents; /* returned events witnessed */
};

将struct pollfd结构体数组拷贝到内核中进行监听。poll采用链表poll_list来进行文件描述符的存储,因此poll可以监听的文件描述符数为系统可以打开的最大文件描述符数(65535)。采用轮询方式,查询每个fd的状态,如果就绪,内核就修改fd对应的revents的值,而events成员保持不变,因此下次调用poll时,应用程序无需重置pollfd类型的事件集参数。将之前传入的struct pollfd结构体数组拷贝传出到用户态,并返回就绪文件描述符的总个数。用户态并不知道是哪些文件描述符处于就绪态,需要遍历来判读。应用程序索引就绪文件描述符的时间复杂度是O(n).poll只能工作在相对较低下的LT模式。

(3)epoll系统调用

int epoll_create(int size);
int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event);
            typedef union epoll_data {
                void *ptr;
                int fd;
                __uint32_t u32;
                __uint64_t u64;
            } epoll_data_t;

            struct epoll_event {
                __uint32_t events;      /* Epoll events */
                epoll_data_t data;      /* User data variable */
            };

int epoll_wait(int epfd, struct epoll_event * events, int maxevents, int timeout);

执行epoll_create()函数会在内核创建一颗红黑树rb_node以及就绪链表rdllist(存放已经就绪的文件描述符),监听的文件描述符数为系统可以打开的最大文件描述符数(65535)。接着用户执行的epoll_ctl()函数将epoll_event结构体拷贝传入内核,内核会在红黑树上添加相应的结点,并注册回调函数ep_poll_callback(),内核在检测到某文件描述符可读/可写时就调用回调函数callback,该回调函数将文件描述符放入就绪链表rdllist中。epoll_wait()函数只需要观察rdllist中有无就绪的文件描述符即可,内核将就绪的文件描述符事件复制到传入的poll_event结构体数组中返回给用户空间,所以用户只用遍历依次处理即可,即应用程序索引就绪文件描述符的时间复杂度是O(1)。这里返回的文件描述符是通过mmap让内核和用户空间共享同一块内存传递的,减少了不必要的拷贝。再次调用epoll系统调用,不用重建红黑树,直接沿用已经存在的即可。epoll支持ET模式,当内核将该事件通知给用户后,用户必须立即处理,这样就减少了可读、可写和异常事件被触发的次数。

二、为什么epoll比select和poll更高效?

(1)减少了用户态和内核态之间文件描述符的拷贝

select创建了3个文件描述符集(fd_set)并拷贝到内核中,分别监听读、写、异常事件。内核分配相关数据结构(fd_set_bits),内核在检测到有就绪事件后,就修改用户传进来的fd_set的值以告知用户有就绪的文件描述符。将文件描述符fd_set拷贝传出到用户态并返回就绪的文件描述符的总个数。内核删除和文件描述符相关的数据结构,由于内核修改了用户传进来的fd_set文件描述符集,下次调用select前必须要重置fd_set,然后重新传给内核,内核在重新拷贝一份,重新分配数据结构。

poll系统调用将struct pollfd结构体数组拷贝到内核中进行监听,内核分配相关数据结构poll_list,用来存储监听的文件描述符,然后调用所有fd对应的poll(将current挂到各个fd对应的设备等待队列上),内核在检测到有就绪事件后,就修改fd对应的revents的值用来告知用户有就绪的文件描述符,而events成员保持不变,因此下次调用poll时,应用程序无需重置pollfd类型的事件集参数。将之前传入的struct pollfd结构体数组拷贝传出到用户态,并返回就绪文件描述符的总个数。内核删除和文件描述符相关的数据结构,下次调用poll需要将struct pollfd重新传给内核,内核在重新拷贝一份,重新分配数据结构。

执行epoll_create()函数会在内核创建一颗红黑树rb_node以及就绪链表rdllist(存放已经就绪的文件描述符),接着用户执行的epoll_ctl()函数将epoll_event结构体拷贝传入内核,内核会在红黑树上添加相应的结点,内核将就绪的文件描述符事件复制到传入的poll_event结构体数组中返回给用户空间,系统调用在返回时采用mmap共享存储区,需要拷贝的次数大大减少。由于epoll创建的有关文件描述符的数据结构本身就存在于内核态中。下一次调用epoll系统调用时,不需要再次拷贝用户空间所要监听的文件描述符,也不需要重新构建红黑树和就绪链表等相关数据结构,直接沿用已经存在的数据结构。

(2)减少了对就绪文件描述符的遍历

扫描二维码关注公众号,回复: 5645112 查看本文章

select和poll采用轮询的方式来检查文件描述符是否处于就绪状态。并且内核修改用户传进来的fd_set和pollfd结构体的成员的revents值以告知用户有文件描述符就绪,但是用户并不知道有哪些文件描述符处于就绪态,需要遍历查找就绪文件描述符,因此,应用程序索引就绪文件描述符的时间复杂度为O(n).

而epoll采用回调机制。在调用epoll_ctl时,已经将用户感兴趣的事件传给了内核,内核会维持一个内核事件表,记录用户感兴趣的事件,就绪事件发生时,驱动设备调用回调函数ep_poll_callback()将就绪的fd挂到rdllist上。用户调用epoll_wait时,将rdllist上就绪的文件描述符发送给用户。此时发送给用户的都是就绪的fd。因此,应用程序索引就绪文件描述符的时间复杂度为O(1)。

(3)select和poll只支持LT模式,而epoll支持高效的ET模式,并且epoll还支持EPOLLONESHOT事件。

LT模式(电平触发):LT模式是默认的工作模式,当检测到文件描述符上有事件发生并将此事件通知给应用程序,应用程序可以不立即处理该事件,下次调用会再次响应应用程序并通知此事件。

ET模式(边沿触发):当检测到文件描述符上有事件发生并将此事件通知给应用程序,应用程序必须立即处理该事件,如果没处理或者没处理完,下次调用不会再响应应用程序并通知此事件。

ET模式很大程度上减少了epoll事件被重复触发的次数,因此效率要比LT模式高,epoll工作在ET模式的时候,必须使用非阻塞的套接字,以避免由于一个文件句柄的阻塞读/阻塞写操作把处理多个文件描述符的任务饿死。

即使使用ET模式,一个socket上的某个事件还是可能被触发多次,这在并发程序中就会引发一个问题。比如一个线程在读取完某个socket上的数据开始处理这些数据的时候,而在数据的处理过程中这个socket上又有新数据可读,这时另一个线程被唤醒来处理新数据,于是就出现了两个线程同时操作一个socket的局面。因此需要使用epoll的EPOLLONESHOT事件实现。对于注册了EPOLLONESHOT事件的文件描述符,操作系统最多触发其上的一个读、写或异常事件,且只触发一次。当一个线程在处理socket时,其它线程是不可能有机会操作该socket的。注册了EPOLLONESHOT事件的socket一旦被某个线程处理完,该线程就应该立即重置这个socket上的EPOLLONESHOT事件,以确保这个socket下次可读时,其EPOLLIN事件可被触发,进而让其它线程有机会处理这个socket。使用EPOLLONESHOT事件能进一步减少可读、可写和异常事件的被触发的次数。

三、无论哪种情况下,epoll都比select和poll高效吗?

epoll适用于连接较多,活动数量较少的情况。
(1)epoll为了实现返回就绪的文件描述符,维护了一个红黑树和好多个等待队列,内核开销很大。如果此时监听了很少的文件描述符,底层的开销会得不偿失;

(2)epoll中注册了回调函数,当有事件发生时,服务器设备驱动调用回调函数将就绪的fd挂在rdllist上,如果有很多的活动,同一时间需要调用的回调函数数量太多,服务器压力太大。

select和poll适用于连接较少的情况。
当select和poll上监听的fd数量较少,内核通知用户现在有就绪事件发生,应用程序判断当前是哪个fd就绪所消耗的时间复杂度就会大大减小。

猜你喜欢

转载自blog.csdn.net/mingwulipo/article/details/88573543