Linux的五种IO模型?

2019-12-25 14:23:50 浏览数 (1)

IO的同步、异步、阻塞、非阻塞

同步、异步

  • 同步synchronous): A 调用 B, B 立刻处理 A 的请求(即使 C 紧接着调用 B),并把最终结果 返回给 A。
  • 异步asynchronous):A 调用 B, B 立刻反馈 A, 仅是状态,并非最终结果。B 处理完 A 的请求, 完成后把 最终结果 返回给 A。

关注:<font color='red'>被调用者 B 是否有消息通知(回调函数)机制 把 最终结果 返回给 A。</font>

阻塞、非阻塞

  • 阻塞blocking):A 调用 B, 在 B 返回结果前,A 会被挂起 (忙等),只有 B 把最终结果 返回给 A, A 才继续处理。
  • 非阻塞non-blocking):A 调用 B, 在 B 返回结果前,A 不会被挂起 (做其他事情)。

关注:<font color='red'>调用者 A 在等被调用者 B 返回结果前的状态。</font>

IO相关概念

用户空间与内核空间

为保证内核的安全,操心系统将内存空间划分为两部分,一部分为内核内存空间,一部分为用户内存空间

  • 操作系统的核心是内核(kernel),独立于普通的用户进程(application),可以访问受保护的内核内存空间,有访问底层硬件设备(hardware)的所有权限。
  • 用户进程(application)只能使用用户内存空间,不能直接操作内核内存空间,没有访问底层硬件设备(hardware)的权限,需要向内核(kernel)发起系统调用(syscall)函数调用,交由内核(kernel)处理。

进程切换

为了控制进程的执行,内核(kernel)必须有能力(通过时钟中断)挂起正在CPU上运行的进程(application),并恢复以前挂起的某个进程的执行。这种行为被称为进程切换

进程的阻塞

正在运行的用户进程(application),可能因为期待的某些事件未发生,如请求系统资源失败、等待某种操作的完成、新数据尚未到达或无新工作做等,则由系统自动执行阻塞原语(Block),使自己由运行状态变为阻塞 (blocking) 状态。

可见,进程的阻塞是进程自身的一种主动行为,也因此只有处于运行态的进程(获得CPU),才可能将其转为阻塞状态。 当进程进入阻塞状态,是不占用CPU资源的。

典型一次IO的两阶段

当一个read操作发生时,涉及到两个系统对象,一个是调用这个IO的process (or thread),另一个就是系统内核(kernel),它会经历两个阶段:

  • 等待数据准备 (Waiting for the data to be ready), 即 用户进程(application) 等待 内核(kernel) 操作底层硬件设备(hardware)读取并准备好数据。
  • 将数据从内核(kernel)拷贝到用户进程(application)中 (Copying the data from the kernel to the process)

Linux的五种IO模型

在Linux(UNIX)操作系统中,共有五种IO模型,分别是:

  • 阻塞IO模型(Blocking I/O)
  • 非阻塞IO模型(non-blocking I/O)
  • IO复用模型(I/O multiplexing)
  • 信号驱动IO模型(signal-driven I/O)
  • 异步IO模型(Asynchronous I/O)

阻塞IO模型(Blocking I/O)

Linux操作系统中,这就是一种最简单的IO模型,即阻塞IO。 阻塞 I/O 是最简单的 I/O 模型,一般表现为进程或线程等待某个条件,如果条件不满足,则一直等下去。条件满足,则进行下一步操作。 用户进程(application)通过系统调用 recvfrom 接收数据,但由于内核(kernel)还未准备好数据报,用户进程(application)就会阻塞(blocking)住,直到内核(kernel)准备好数据,并完成数据复制工作,用户进程(application)才能结束阻塞状态。

  • 用户进程(application) 在两阶段都是阻塞 (blocking) 状态。
  • 内核(kernel)在两阶段都是同步(synchronous)状态。

非阻塞IO模型(non-blocking I/O)

用户进程(application)通过 recvfrom 调用不停的去和内核(kernel)交互,直到内核(kernel)准备好数据。如果没有准备好,内核会返回error,用户进程在得到error后,过一段时间再发送recvfrom请求。在两次发送请求的时间段,进程(application)可以先做别的事情。

  • 用户进程(application) 在第一阶段是非阻塞 (non-blocking) 状态, 在第二阶段是阻塞 (blocking) 状态。
  • 内核(kernel)在两阶段都是同步(synchronous)状态。

IO复用模型(I/O multiplexing)

多了一个select函数,多个用户进程(application)的IO可以注册到同一个select上,当用户进程(application)调用该select,select会监听所有注册好的IO,如果所有被监听的IO需要的数据都没有准备好时,select调用进程会阻塞。当任意一个IO所需的数据准备好之后,select调用就会返回,然后进程在通过recvfrom来进行数据拷贝。

  • 用户进程(application) 在两阶段都是阻塞 (blocking) 状态。
  • 内核(kernel)在两阶段都是同步(synchronous)状态。
  • 与 阻塞IO模型(Blocking I/O) 的区别在于 它将两阶段 切为两个步骤函数,提高了处理的吞吐率。

信号驱动IO模型(signal-driven I/O)

用户进程(application)预先向内核注册一个信号处理函数,然后用户进程返回,并且不阻塞,当内核(kernel)数据准备就绪时会发送一个信号给进程,用户进程便在信号处理函数中开始把数据拷贝的用户空间中。

  • 用户进程(application) 在第一阶段是非阻塞 (non-blocking) 状态, 在第二阶段是阻塞 (blocking) 状态。
  • 内核(kernel)在第一阶段都是异步(asynchronous) 状态, 在第二阶段是同步(synchronous)状态。
  • 与 非阻塞IO模型(non-blocking I/O) 的区别在于 它提供了消息通知机制,不需要用户进程(application) 定时去检查。

异步IO模型(Asynchronous I/O)

用户进程(application)发起aio_read操作之后,给内核(kernel)传递描述符、缓冲区指针、缓冲区大小等,告诉内核当整个操作完成时,如何通知进程,然后就立刻去做其他事情了。当内核(kernel)收到aio_read后,会立刻返回,然后内核开始等待数据准备,数据准备好以后,直接把数据拷贝到用户空间,然后再通知进程(application)本次IO已经完成。

  • 用户进程(application) 在整体阶段是非阻塞 (non-blocking) 状态。
  • 内核(kernel)在整体阶段是异步(asynchronous)状态。

横向对比

钓鱼例子:

  • 阻塞IO模型(Blocking I/O):

我们坐在鱼竿面前,这个过程中我们什么也不做,双手一直把着鱼竿,就静静的等着鱼儿咬钩(第一阶段我是阻塞的,鱼竿是同步的)。一旦手上感受到鱼的力道,就把鱼钓起来放入鱼篓(第二阶段我是阻塞的,鱼竿是同步的)中。然后再钓下一条鱼。

  • 非阻塞IO模型(non-blocking I/O):

我们钓鱼的时候,在等待鱼儿咬钩的过程中,我们可以做点别的事情,比如玩一把王者荣耀、看一集《延禧攻略》等等。但是,我们要时不时的去看一下鱼竿,一旦发现有鱼儿上钩了(第一阶段我是非阻塞的,鱼竿是同步的),就把鱼钓起来放入鱼篓(第二阶段我是阻塞的,鱼竿是同步的)中。然后再钓下一条鱼。

  • IO复用模型(I/O multiplexing)

我们钓鱼的时候,为了保证可以最短的时间钓到最多的鱼,我们同一时间摆放多个鱼竿,同时钓鱼。然后哪个鱼竿有鱼儿咬钩了(第一阶段我是阻塞的,鱼竿是同步的),我们就把哪个鱼竿上面的鱼钓起来放入鱼篓(第二阶段我是阻塞的,鱼竿是同步的)中。然后再钓下一条鱼。

  • 信号驱动IO模型(signal-driven I/O)

我们钓鱼的时候,为了避免自己一遍一遍的去查看鱼竿,我们可以给鱼竿安装一个报警器。当有鱼儿咬钩的时候立刻报警(第一阶段我是非阻塞的,鱼竿是异步的)。然后我们再收到报警后,去把鱼钓起来放入鱼篓(第二阶段我是阻塞的,鱼竿是同步的)中。然后再钓下一条鱼。

  • 异步IO模型(Asynchronous I/O)

我们钓鱼的时候,采用一种高科技钓鱼竿,即全自动钓鱼竿。可以自动感应鱼上钩,自动收竿,更厉害的可以自动把鱼放进鱼篓里。然后,通知我们鱼已经钓到了,他就继续去钓下一条鱼去了。(两阶段我是非阻塞的,鱼竿是异步的)

最后我们总结:

by 斯武丶风晴 https://my.oschina.net/langxSpirit

0 人点赞