前往小程序,Get更优阅读体验!
立即前往
发布
社区首页 >专栏 >【Linux】从零开始使用多路转接IO --- 理解EPOLL的 LT水平触发模式 与 ET边缘触发模式

【Linux】从零开始使用多路转接IO --- 理解EPOLL的 LT水平触发模式 与 ET边缘触发模式

作者头像
叫我龙翔
发布2024-11-10 08:02:20
发布2024-11-10 08:02:20
1470
举报
文章被收录于专栏:就业 C++ 综合学习

当你偶尔发现语言变得无力时,

不妨安静下来,

让沉默替你发声。

--- 里则林 ---


1 EPOLL优缺点

poll 的优点(和 select 的缺点对应)

  1. 接口使用方便:虽然拆分成了三个函数,但是逻辑清晰,使用起来更方便高效。不需要每次循环都设置关注的文件描述符,并且做到了输入输出参数分离开!
  2. 数据拷贝轻量:只在合适的时候调用 EPOLL_CTL_ADD 将文件描述符结构拷贝到内核中,这个操作并不频繁(而 select/poll 都是每次循环都要进行拷贝)。
  3. 事件回调机制:避免使用遍历, 而是使用回调函数的方式,将就绪的文件描述符结构加入到就绪队列中。epoll_wait 返回直接访问就绪队列就知道哪些文件描述符就绪。这个操作时间复杂度 O(1). 即使文件描述符数目很多,效率也不会受到影响。
  4. 没有数量限制:理论上,文件描述符数目是无上限。epoll的接口支持无上限的文件描述符!

网上说:epoll 中使用了内存映射机制

  • 内存映射机制: 内核直接将就绪队列通过 mmap 的方式映射到用户态。 避免了拷贝内存这样的额外性能开销。

这种说法是不准确的。我们定义的 struct epoll_event 是我们在用户空间中分配好的内存。势必还是需要将内核的数据拷贝到这个用户空间的内存中的。

可以这么说epoll几乎没有缺点!

2 EPOLL工作模式

select、poll、epoll都存在一个现象:当有事件就绪时,用户不处理就会一直通知用户处理,循环打印日志信息。

EPOLL的工作模式有两种:

  1. LT水平触发
  2. ET边缘触发

上面现象是LT模式下的产物,那么怎么理解LT与ET呢?我们通过快递小哥的例子进行讲解:

有两名快递员张三李四,他们一个温和老实,一个严肃霸道。 小明前几天买了5个包裹,今天一起送到了快递站。张三李四分别分到了小明的3个包裹和2个包裹。 张三首先到达了小王所在的小区,他给该小区所以的收件人都打了一遍电话:“请你下来拿快递”。小明这时正在和舍友打无畏契约,拿不了快递。过了一会张三再次给小明打电话让他下来拿快递,小明下去取了一个就立马回去了。张三一看,还有两个包裹啊,于是又给小王打电话!这时李四过来了,把两个快递交给了张三。张三就在这里一直打电话 第二天,又有小明的5个包裹,这次李四来到小区门口,开始打电话:我只给你打一次电话,你有快递到了,不拿我就走人。小明一听,这快递小哥这么硬气,哎我就不拿,那你怎么办。于是小明就没有去拿,结果李四真的走了。一会碰到了张三,张三把小明的包裹给了李四,于是李四又来到小区门口,再一次强硬的打电话。小明决定去拿了,快递不拿他是真走啊!

这里我们可以总结出来:

  1. 张三:只有底层有快递,就一直打电话给小王。
  2. 李四:只有包裹变化的时候,我才来通知你拿快递。

在这个例子中,快递就是数据,张三对应LT水平触发模式,李四对应ET边缘触发模式。一般情况下是LT水平触发模式。

这两种模式哪一个更加高效呢?ET模式更加高效!毕竟李四比张三打的电话少的多得多!

LT水平触发是默认的,那么一个如何设置成ET边缘触发模式呢?

  • 通过EPOLLET 标志位: 将 EPOLL 设为边缘触发(Edge Triggered)模式, 这是相对于水平触发(Level Triggered)来说的
  1. 水平触发 Level Triggered 工作模式
    • epoll 默认状态下就是 LT 工作模式。
    • 当 epoll 检测到 socket 上事件就绪的时候, 可以不立刻进行处理. 或者只处理一部分。
    • 如上面的例子, 由于只读了 1K 数据,缓冲区中还剩 1K 数据,在第二次调用epoll_wait 时, epoll_wait 仍然会立刻返回并通知 socket 读事件就绪。
    • 直到缓冲区上所有的数据都被处理完, epoll_wait 才不会立刻返回。
    • 支持阻塞读写和非阻塞读写。
  2. 边缘触发 Edge Triggered 工作模式
    • 如果将 socket 添加到 epoll 描述符的时候使用了 EPOLLET 标志,epoll 进入 ET 工作模式。
    • 当 epoll 检测到 socket 上事件就绪时,必须立刻处理。
    • 如上面的例子,虽然只读了 1K 的数据,缓冲区还剩 1K 的数据,在第二次调用epoll_wait 的时候,epoll_wait 不会再返回了。
    • 也就是说, ET 模式下,文件描述符上的事件就绪后,只有一次处理机会。
    • ET 的性能比 LT 性能更高( epoll_wait 返回的次数少了很多). Nginx 默认采用ET 模式使用 epoll。
    • 只支持非阻塞的读写

假如服务端使用ET模式,这时服务端需要的数据是10K,客户端将这10K数据发过来,服务端第一次只读取了1K的数据。由于是ET模式,在客户端发送新的数据之前,服务端一直不会进行读取!所以ET模式下,必须一次性将数据读完,就要进行循环读取直到读取不到!这样也就必须使用非阻塞的读取了(才能支持循环读取)!LT模式没有这种问题。

  • ET模式的这种读取方式也就决定了TCP应答中TCP服务端的窗口更大,客户端下一次可以发送更多的数据!增加IO效率!

那么LT设置成非阻塞呢?那么是不是和ET模式一样了呢?所以一般不能说ET模式一定比LT模式的效率更高。可是,ET强制程序员必须使用非阻塞进行读取!LT不会强制程序员使用非阻塞读取!所以可以认为ET模式更加高效

本文参与 腾讯云自媒体同步曝光计划,分享自作者个人站点/博客。
原始发表:2024-11-08,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 作者个人站点/博客 前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 1 EPOLL优缺点
  • 2 EPOLL工作模式
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档