IO的同步、异步、阻塞、非阻塞
同步、异步
- 同步(
synchronous
): A 调用 B, B 立刻处理 A 的请求(即使 C 紧接着调用 B),并把最终结果 返回给 A。 - 异步(
asynchronous
):A 调用 B, B 立刻反馈 A, 仅是状态,并非最终结果。B 处理完 A 的请求, 完成后把 最终结果 返回给 A。
关注:被调用者 B 是否有消息通知(回调函数)机制 把 最终结果 返回给 A。
阻塞、非阻塞
- 阻塞(
blocking
):A 调用 B, 在 B 返回结果前,A 会被挂起 (忙等),只有 B 把最终结果 返回给 A, A 才继续处理。 - 非阻塞(
non-blocking
):A 调用 B, 在 B 返回结果前,A 不会被挂起 (做其他事情)。
关注:调用者 A 在等被调用者 B 返回结果前的状态。
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