IO模型
同步/异步:关注的是消息通知机制
同步: synchronous,调用者自己主动等待被调用者返回消息,才能继续执行
异步: asynchronous,被调用者通过状态,通知或回调机制主动通知调用者的运行状态
阻塞/非阻塞:关注调用者在等待结果返回之前所处的状态
阻塞: blocking,指IO操作需要彻底完成后才能返回到用户空间,调用结果返回之前,调用者被挂起
非阻塞: nonblocking,指IO操作被调用后立即返回给用户一个状态值,无需等待IO操作策底完成,最终的调用结果返回之前,调用者不会被挂起
IO模型:
阻塞型,非阻塞型,复用IO型,事件驱动型,异步
同步阻塞IO模型
同步阻塞IO模型是最简单的IO模型,用户线程在内核进行IO操作时被阻塞
用户线程通过系统调用read发起IO操作,由用户空间转到内核空间,内核等到数据包到达后,然后将接收的数据拷贝到用户空间,完成read操作
用户需要等待read将数据读取到buffer中,才继续处理接收的数据.整个IO请求的过程中,用户线程是被阻塞的,这导致用户在发起IO请求的时候,不能做任何事,对cpu的资源利用率不高
同步非阻塞IO模型
用户线程发起IO请求立即返回,但并未读取任何数据,用户线程需要不断发起IO请求,直到数据到达后,才真正读取到数据,继续执行.即"轮询"机制
整个IO请求的过程中,虽然用户线程每次发起IO请求后可以立即返回,但是为了等到数据,仍需要不断地轮询,重复请求,消耗了大量的cpu的资源
是比较浪费CPU的方式,一般很少直接使用这种模型,而是在其他IO中使用非阻塞IO这一特性
IO多路复用模型
IO多路复用是指内核一旦发现进程指定的一个或多个IO条件准备读取,他就通知该进程
IO多路复用适合如下场合:
当客户端处理多个描述符时(一般会是交互式输入和套接字接口),必须使用I/O复用
当一个客户端同时处理多个套接字时,此情况可能的但很少见出现
当一个TCP服务器既要处理监听套接口,有要处理已连接套接字,一般也要用到IO复用
当一个服务器即要处理TCP,又要处理UDP,一般要使用IO复用
当一个服务器要处理多个服务或多个协议,一般要使用IO复用
多个连接共用一个等待机制,本模型会阻塞进程,但是进程是阻塞在select或者poll这两个系统调用上,而不是阻塞在真正的IO操作上
用户首先需要进行IO操作添加到select中,继续执行做其他的工作(异步),等待select系统调用返回,当数据到达时,IO被激活,select函数返回.用户线程正式发起read请求,读取数据并继续执行
从流程上来看,使用select函数进行IO请求和同步阻塞模型没有多大区别,甚至还多了添加监视IO,以及调用select函数的额外操作,效率更差,并且阻塞了两次,但是第一次阻塞在select上时,select可以监控多个IO上是否有IO操作准备继续,即可达到在同一个线程内同时处理多个IO请求的目的,而不像阻塞IO那种,一次只能监控一个IO
虽然上述方式允许单线程内处理多个IO请求,但是每个IO请求的过程还是阻塞的(在select函数上阻塞),平均时间甚至比同步阻塞IO模型还要长,如果用户线程只是注册自己需要的IO请求,然后去做自己的事情,等到数据到来时在进行处理,则可以提高cpu的利用率
IO多路复用是最常见的IO模型,但是其异步程度还不够"彻底",因为它使用了会阻塞线程的select系统调用.因此IO多路复用只能称为异步阻塞IO模型,而非真正的异步IO
信号驱动模型
信号驱动IO: signal-driven IO
用户进程可以通过sigaction系统调用注册一个信号处理程序,然后主程序可以继续向下执行,当有IO操作准备就绪时,由内核通知触发一个SIGIO信号处理程序执行,然后将用户进程所需的数据从内核空间拷贝到用户空间
此模型的优势在于等待数据报到达期间进程不被阻塞.用户主程序可以继续执行,只要等待来自信号处理函数的通知
该模型并不常用
异步IO模型
异步IO与信号驱动IO最主要的区别是信号驱动IO是由内核通知何时进行IO操作,而异步IO则是由内核告诉我们IO操作何时完成,具体来说是,信号驱动IO当内核通知触发信号处理程序时,信号处理程序还需要阻塞在从内核空间缓冲区拷贝数据到用户空间缓冲区这个阶段,而异步IO直接是在第二阶段完成后直接通知可以进行后续操作了
相比于IO多路复用模型,异步并不常用,不少高性能并发服务器程序使用IO多路复用模型+多线程任务处理的架构基本可以完成需求,况且目前操作系统对异步IO的支持并非特别完善,更多的采用IO多路复用模型异步IO的方式(IO事件触发时,直接通知用户线程,而是将数据读写完毕后放到用户指定的缓冲区中)
-
五种模型
