Linux I/O模型的前世今生

Linux I/O模型

  • 阻塞式I/O模型
  • 非阻塞式I/O模型
  • I/O复用式模型
  • 信号驱动式I/O模型
  • 异步I/O模型

同步I/O与异步I/O的区别

对于I/O操作有两个对象,一个是调用I/O操作的应用进程,一个是Linux系统内核。当进程发起read操作,通常包含有两个不同的阶段。

  • 等待数据就绪(可读)
  • 将数据从内核复制到进程(用户空间)

I/O模型的区别就是在这两个阶段上有不同的情况。

同步I/O操作(synchronous I/O operation)会导致进程被阻塞,直到I/O操作完成。参照《unix网络编程》,里面提到的5中I/O模型里面其中4中都是同步I/O模型,分别是阻塞式/O模型、非阻塞式I/O模型、I/O复用模型、信号驱动式I/O模型,因为里面真正的I/O操作将阻塞进程。

异步I/O操作(asynchronous I/O operation)不导致进程阻塞。

同步I/O和异步I/O的真正的区别是真正的I/O操作是否会导致进程阻塞。具体表现为同步I/O需要进程真正的操作I/O,而异步I/O等待内核完成I/O操作后,再通知应用程序结果。

阻塞式I/O模型

image.png

如图所示,recvfrom函数为系统调用,因为我们要区分到底是应用进程还是系统内核。进程调用recvfrom函数,系统调用直到数据报准备好且被复制到应用进程的缓冲区(用户空间)或者发送错误才返回。应用进程在调用recvfrom函数到返回这段期间都是被阻塞的。recvfrom函数返回成功后,应用进程才开始处理数据报。

非阻塞式I/O模型

进程把一个套接字设置成非阻塞是在通知内核:当所请求的I/O操作非得把本进程投入睡眠才能完成时,不要把本进程投入睡眠,而是返回一个错误。


image.png

前三次调用recvfrom时没数据返回,因而内核返回ewouldblock错误。第四次调用recvfrom时已有一个数据报准备好,它被复制进应用进程缓冲区,于是recvfrom成功返回后,应用进程处理数据报。

当一个应用程序对非阻塞描述符循环调用recvfrom时,我们称之为轮询(polling)。应用程序持续轮询内核,查看某个操作是否就绪,往往耗费了大量的CPU时间。

I/O复用模型

关于I/O复用模型,一个通俗的解释是是“事件驱动”。操作系统为你提供了一个功能,当你的某个socket可读或者可写时,它可以给你一个通知。这样配合非阻塞的socket使用时,只有当系统通知应用程序哪个描述符可读时,应用程序才去执行read操作,可以保证每次read都能读到有效的数据而不用纯返回-1或者是EAGAIN的无用功。操作系统是是通过select/poll/epoll/kqueue之类的系统调用函数来实现的。这些函数都可以同时监视多个描述符的就绪状况。

多路复用是指使用一个线程来检查多个文件描述符(Socket)的就绪状态,比如调用select和poll函数,传入多个文件描述符(FileDescription,简称FD),如果有一个文件描述符(FileDescription)就绪,则返回,否则阻塞直到超时。得到就绪状态后进行真正的操作可以在同一个线程里执行,也可以启动线程执行(比如使用线程池)。

有了I/O复用(I/O multiplexing),我们就可以调用select或poll,阻塞在这两个系统调用中的某一个之上,而不是阻塞在真正的I/O系统调用上。下图概括展示了I/O复用模型:


image.png

我们阻塞于select调用,等待数据报套接字变为可读。当select返回套接字可读这一条件时,我们调用recvfrom把所读数据报复制到应用进程缓冲区。

I/O复用并不显得有什么优势,事实上由于使用select需要两个而不是单个系统调用,I/O复用还稍有劣势。不过select的优势在于可以等待多个描述符就绪(与此相对应的方法是多线程+阻塞式I/O,即由每一个线程来调用阻塞式I/O系统调用)。

信号驱动式I/O模型

让内核在描述符就绪时发送SIGIO信号给信号处理程序通知应用程序。这种模型为信号驱动式I/O模型。


image.png

首先开启套接字的信号驱动式I/O功能,并通过sigaction系统调用安装一个信号处理函数。该系统调用立即返回,我们的进程继续工作,也就是程序并没有被阻塞。当数据报准备好读取时,内核为该进程产生一个SIGIO信号。我们可以直接在信号处理函数中调用recvfrom读取数据报,并通知主循环数据已准备好待处理,也可以立即通知主循环,让它读取数据报。

无论如何处理SIGIO信号,这种模型的优势是在于等待数据到达期间进程不会被阻塞。主线程可以继续执行,只要等待来自信号处理函数的通知:即可以是数据报已准备好被处理,也可以是数据报准备好被读取。

异步I/O模型

异步I/O模型(asynchronous I/O)由POSIX规范定义。异步I/O的工作机制是告知内核启动某个操作,并让内核在整个操作(包括把数据从内核复制到应用的缓冲区)完成后通知我们。这种模型与前面介绍的信号驱动模型的主要的区别是:信号驱动I/O告知我们何时可以启动一个I/O操作,而异步I/O模型告知我们I/O操作何时完成。


image.png

我们调用aio_read函数,给内核传递描述符、缓冲区指针、缓冲区大小和文件偏移,并告诉内核当整个操作完成时如何通知我们。该系统调用立即返回,而且在等待I/O完成期间,我们的进程并不会被阻塞。本例子中我们假设要求内核在操作完成后产生某个信号。该信号直到数据复制到应用进程缓冲区才产生,这一点不同于驱动式I/O模型。

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 215,012评论 6 497
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 91,628评论 3 389
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 160,653评论 0 350
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 57,485评论 1 288
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 66,574评论 6 386
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 50,590评论 1 293
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 39,596评论 3 414
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 38,340评论 0 270
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 44,794评论 1 307
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 37,102评论 2 330
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 39,276评论 1 344
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 34,940评论 5 339
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 40,583评论 3 322
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 31,201评论 0 21
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,441评论 1 268
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 47,173评论 2 366
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 44,136评论 2 352

推荐阅读更多精彩内容