Linux --- 高级IO

1. 什么是IO

2. 阻塞的本质

3. 五种IO模型

3.1. 通过故事认识五种IO模型

3.2. 上述故事的总结

3.3. 具体的五种IO模型

3.3.1. 阻塞IO

3.3.2. 非阻塞轮询式IO

3.3.3. 信号驱动IO

3.3.4. 多路转接IO

3.3.5. 异步IO

4. 非阻塞IO

4.1. fcntl 系统调用

1. 什么是IO

冯诺依曼体系：

站在冯诺依曼体系的视角，从输入设备读取数据到存储器，这个过程就是Input；而将存储器的数据写入到输出设备，这个过程就是Output；

因此，IO本质上就是访问外设的过程。

因为外设相较于内存、cache缓存、寄存器、CPU的速率是比较低的，故IO的效率是比较低的，尤其涉及到网络，效率问题就更加突出。

2. 阻塞的本质

IO过程的低效，我们可以用读取数据为例：

当进程 read/recv 时，如果底层缓冲区没有数据，read/recv 会被阻塞；

当进程 read/recv 时，如果底层缓冲区有数据， read/recv 会将数据从内核缓冲区拷贝到应用层；

阻塞的本质：

站在操作系统的视角：将该进程的PCB放在等待队列中；
站在进程自身的视角：本质上就是让我这个进程等待；

因此，当进程等了 (等待事件就绪)，数据就绪后，再进行数据拷贝，这就是一次IO过程；

故我们认为，IO = 等待 (事件就绪) + 数据拷贝；

因此， read、recv、write、send 等，本质上都是先等待IO类事件就绪，在进行数据拷贝 (内核将数据拷贝给用户或者用户将数据拷贝给内核)；

那么什么叫做低效的IO呢？

根据 IO = 等待 (事件就绪) + 数据拷贝，我们发现，单位时间，只要等待的比重越高，那么这个IO过程就越低效；

因此，那什么叫做高效的IO呢？即如何提高IO效率？

在单位时间，让等待的比重变得越低，那么IO的效率就变得越高，因此，高效IO的本质：降低IO过程中等待的比重，提高单位时间内拷贝数据的量；

3. 五种IO模型

3.1. 通过故事认识五种IO模型

通过一个钓鱼故事，来认识这五种IO模型：

今天，我们对钓鱼的过程进行简化一下（不要考虑什么打窝的事情了😄😄😄），我们认为钓鱼就分两步：

step 1：等待鱼上钩，等待事件就绪；
step 2：鱼上钩后，把鱼钓起来，数据拷贝。

根据上面对IO的简单理解，类比到钓鱼过程中，什么情况下，一个人钓鱼的效率非常高呢？

钓鱼 = 等待 + 钓起来；
因此，只要单位时间等待的比重非常低，那么这个人钓鱼的效率一定非常高。

下面我们就通过一个故事，来认识下五种IO模型：

张三是一个钓鱼爱好者，带着帽子、墨镜、马扎，就来到鱼塘边，在钓鱼过程中：

张三死死的盯着鱼漂，其他事情都不做，鱼漂不动，他也不动，过了一会，鱼漂动了，张三就将鱼钓上来，这是张三；

李四是张三的老朋友，路过鱼塘时，看到张三在钓鱼，自己也拿着鱼竿去钓鱼了，在钓鱼过程中：

李四一会儿刷下手机，一会儿和张三聊天 ( 当然张三没理他 )，一会儿又盯着鱼漂，反正一直没闲着，过了一会儿，鱼漂动了，他抬头看了一眼，就将鱼钓了起来，这是李四；

王五也是一个钓鱼爱好者，路过鱼塘，也拿着鱼竿跑过来了，王五与前两者相比，多做了一步，他在鱼漂的位置挂了一个铃铛🔔，只要鱼漂一动，铃铛就会响，在钓鱼过程中：

王五一会儿看下张三、一会儿又和李四闲聊、一会儿又刷手机，在整个钓鱼过程中，反正王五就是不看鱼漂，过了一会儿，铃铛🔔响了，他头都不抬，直接收杆，将鱼钓起来了，这是王五；

赵六家是卖鱼竿的，路过鱼塘时，也想钓鱼，就从家里拿了100只鱼竿，将这些鱼竿全都用上，在钓鱼过程中：

因为挂了100只鱼竿，一会儿这边的鱼漂动了，一会儿那边的鱼漂动了，所以赵六就来回的跑，陆陆续续的鱼被钓上来了，这是赵六；

田七作为全村的首富，有一个司机叫小吴，这天，田七坐着豪华轿车路过鱼塘，看到鱼塘边的四个奇葩，一个一动不动，像个石头一样；一个像是多动症一样的；一个一直不看鱼漂；一个挂了密密麻麻的鱼竿，来回跑的汉子；

田七虽然不是非常想钓鱼，但是他却想吃鱼，因此对小吴说，咱去钓鱼，但是小吴说，不行，老板，你要去公司开会，不能钓鱼；田七想了想，行，这样，你帮我去钓鱼，我自己去公司，鱼钓上后，你给我打电话，我再过来；于是，小吴就去帮田七钓鱼去了，田七自己开车去公司开会了，这是田七；

3.2. 上述故事的总结

张三的钓鱼方式：阻塞式；

李四的钓鱼方式：非阻塞轮询式；

王五的钓鱼方式：信号驱动；

赵六的钓鱼方式：多路转接 (或多路复用)；

田七的钓鱼方式：异步IO；

这五种方式，我们称之为五种IO模型；

谁钓鱼最高效呢？为什么？

赵六钓鱼是最高效的，因为：

站在鱼🐟的角度，鱼🐟正在水里游哉悠哉的游着，抬头一看，看到104个食物 (诱饵) 在我的眼前，假设鱼🐟咬任何一个食物 (诱饵) 是等概率的，那么如果此时鱼🐟咬钩了，这个诱饵有 100/104，即25/26的概率是赵六的鱼饵；
站在钓鱼者的角度，因为赵六的鱼竿很多，所以鱼🐟咬钩有很大概率咬的是赵六的鱼竿，所以赵六有很大概率钓上鱼，故在单位时间内，赵六等待的比重是非常低的，因此，赵六钓鱼的效率是非常高的。

只要一个执行流 (进程、线程) 参与了IO过程，我们就称之为同步IO；

IO的过程分两步：

等待事件就绪；
拷贝数据。

因此只要执行流参与了上述的任何一步、或者两者都参与了，那么我们就称之为同步IO；

故，在上面的五种IO模型中，前四种 (阻塞式、非阻塞轮询式、信号驱动、多路转接) 我们都称之为同步IO；

而对于最后一种，即田七的钓鱼方式而言，他既没有等待鱼🐟咬钩 (等待事件就绪)，也没有钓起鱼🐟 (拷贝数据)，故我们将这种IO方式，称之为异步IO；

王五的信号驱动算同步IO吗？

首先，王五的信号驱动是同步IO，可是，我们知道，信号的产生是异步的，这如何解释呢？
因为IO = 等待事件就绪 + 拷贝数据，虽然王五在等待过程中，可以做其他事情，但是一旦鱼咬钩了，王五是会将其钓上来的，换言之，当底层缓冲区有数据后，王五会进行数据拷贝，即王五是会参与IO过程的，故信号驱动这种方式也属于同步IO；
虽然信号产生的确是异步的，但是当信号产生之后，信号驱动是要参与IO过程的，故信号驱动属于同步IO；
换言之，我们认为，只要一个执行流参与了IO过程 (等待事件就绪 + 拷贝数据)，我们就认为它是一个同步IO；
如果一个执行流在整个IO过程都没有参与，完全脱离，那么就是异步IO；

阻塞IO和非阻塞轮询式IO，它们的区别是什么呢？

首先，阻塞IO和非阻塞轮询式IO都属于同步IO，因为它们都要参与IO过程 (等待数据就绪 + 拷贝数据)；

其次，阻塞IO和非阻塞轮询式IO的主要区别就在于：等待数据就绪，这个等的比重不一样罢了，前者阻塞等待，后者非阻塞等待；

我们是学习过系统知识的，IO是谁在IO呢？当然是执行流在IO；

因此，阻塞式IO，我们可以理解为执行流去检测某个文件描述符上是否有事件就绪，如果没有就绪，执行流就阻塞等待，等待事件就绪；

那什么是阻塞呢？

站在操作系统的视角，就是把该执行流的PCB的状态由R -> !R状态，比如S状态，并将该PCB链入到某个等待队列中，这个队列一般都是与该执行流所等待的文件描述符相匹配的；
此时这个执行流就被挂起阻塞了，后续就需要操作系统帮助处理了，比如操作系统识别到某个事件就绪，那么操作系统将在该文件描述符下等待的相关执行流唤醒，状态更改为R状态，并将PCB链入到运行队列中，此时这个执行流不就可以继续被调度，拷贝数据了吗？

多提一嘴，一般而言，执行流在等待什么，什么就需要提供相关队列，或者其他数据结构；

比如，执行流等待某个条件变量，那么条件变量需要自身提供一个等待队列；
再比如，执行流等待某个文件描述符，那么该文件描述符也需要提供一个等待队列。

那么什么是非阻塞呢？

非阻塞，就是不阻塞啊，站在操作系统的视角，如果一个执行流检测某个文件描述符上的事件不就绪时，那么操作系统不会去更改这个执行流的状态，也不会将它的PCB链入到等待队列中，换言之，此时，操作系统并不关心，也不处理；
因此，在非阻塞情况下，执行流不会被阻塞，故它可以在整个IO过程中不断的检测事件是否就绪，如果不就绪，可以处理其他任务，并稍后在进行检测，而这种模式不就是轮询过程吗？

不知道各位有这样的疑惑吗？线程同步和同步IO这两个有关系吗？

先说答案，毫无关系；
线程同步：在多线程场景下，多执行流协同工作时，为了解决访问临界资源合理性的问题，让执行流可以按照特定的顺序访问临界资源，我们称之为线程同步；
同步IO：一个执行流在进行IO时，如果参与了IO过程 (等待事件就绪或者拷贝数据)，我们就认为它是同步IO；
线程同步是在多线程场景下，多执行流进行协同工作时，才会谈论的；
同步IO是在IO过程中，才会谈论的；
可见，线程同步和同步IO的应用场景都不相同，因此，这两者毫无关联。

3.3. 具体的五种IO模型

3.3.1. 阻塞IO

阻塞IO：在内核将数据就绪之前，系统调用会一直等待 (阻塞等待)，所有的文件描述符或者套接字，默认都是阻塞方式；

3.3.2. 非阻塞轮询式IO

非阻塞轮询式IO：如果内核还未将数据准备好，系统调用仍然会直接返回，并且返回 EWOULDBLOCK (Error Would Block)错误码；

非阻塞IO往往需要以循环的方式反复读写文件描述符，这个过程称之为轮询，非常消耗CPU的资源，一般只会在特定场景下使用。

3.3.3. 信号驱动IO

内核将数据准备好的时候，使用SIGIO信号通知执行流进行IO操作。

从下图我们也可以看出，信号驱动这个等，并不是等待信号产生 (信号产生是异步的)，而是等待数据，数据就绪后，内核会向执行流发送信号 (SIGIO)，应用程序在拷贝数据；

3.3.4. 多路转接IO

多路转接可以同时处理多个文件描述符，并且它只负责IO过程中的一个过程：等待事件就绪(数据拷贝它不关心，也不处理)。

多路转接虽然也是阻塞等待，但是它与前面不同的是，它可以同时阻塞等待多个文件描述符，将多个文件描述符的等待时间重叠在一起，这些文件描述符可以在任意时刻就绪，只要其中一个文件描述符的事件就绪了，上层就可以处理这个文件描述符，此时上层绝不会被阻塞，因为此时这个事件已经就绪；
通过多路转接，执行流可以将对多个文件描述符的IO操作集中在一起等待，当其中任何一个文件描述符上的IO事件就绪时，就会通知应用程序，从而避免了阻塞并提高了IO效率。

3.3.5. 异步IO

可以看到，在整个IO过程中，这个应用程序没有参与其中，表现为，既没有等待数据就绪，也没有拷贝数据，因此，该执行流完全脱离IO过程，故它是异步IO；
在整个IO过程中，等待数据就绪是内核完成的，将数据在内核和应用层拷贝也是操作系统进行的，数据拷贝完成后，通知应用程序；
在整个IO过程中，应用程序可以在此期间处理其他任务。

4. 非阻塞IO

一个文件描述符或者套接字，默认情况下，都是阻塞式IO，而接下来，我们需要自己通过 fcntl 系统调用将特定文件描述符设定为非阻塞；

因此，我们先来见见 fcntl 系统调用吧 😊~~~~。

当然，也有其他的方法可以设置为非阻塞，比如，open 打开一个文件时，有一个选项，O_NONBLOCK 或者 O_NDELAY。

还比如，创建一个套接字时，我们也可以设置选项，SOCK_NONBLOCK，设置为非阻塞；

但在后续处理过程中，对于文件描述符或者套接字，我们都会使用 fcntl 系统调用接口，以一种统一的方式来设置非阻塞；

事实上，一个文件在读写数据时，阻塞和非阻塞无外乎就是文件的一个属性罢了；

4.1. fcntl 系统调用

fcntl() 是一个Linux系统调用，用于对文件描述符 (flie descriptor) 进行控制操作。

它的第二个参数 cmd 是一个整数，指定了要执行的操作类型，其余的参数取决于具体的操作类型。
函数原型如下：

man 2 fcntl --- 在2号手册
NAME
    fcntl --- manipulate file descriptor
SYNOPSIS
    #include <unistd.h>
    #include <fcntl.h>
    int fcntl(int fd, int cmd, ... /* arg */ );

RETURN VALUE
    on error, -1 is returned, and errno is set appropriately.
    For a successful call, the return value depends on the operation.

fcntl 根据传入的值不同，其可变参数也不相同，在这列举几个，详细请看手册，或者文档：

F_SETFL：获取文件状态标志；
F_GETFL：设置文件状态标志；
F_DUPFD：复制文件描述符；
F_SETFD：设置文件描述符标志；
F_GETFD：获取文件描述符标志；
F_SETLK：设置文件锁；
F_GETLK：获取文件锁；

通过 fcntl() 系统调用将特定文件描述符设置为非阻塞的大致思路：

通过 cmd = F_GETFL 在底层获取当前文件描述符的文件状态标志，这个文件状态标志可以理解为一个位图；
通过 cmd = f_SETFL 设置当前文件描述符的文件状态标志，因为目的是非阻塞，故：文件状态标志按位或 O_NONBLOCK，这里的文件状态标志就是步骤1获得的文件状态标志。

如下：

bool SetNonBlock(int fd)
{
  // 步骤一
  // 通过F_GETFL获取当前fd对应的文件状态标志
  // 可以将该文件状态标志(fl)理解为一个位图
  int fl = fcntl(fd, F_GETFL);
  if(fl == -1)
  {
    std::cout << "fcntl error" << std::endl;
    return false;
  }

  // 步骤二
  // 获取文件描述符的文件状态标志成功后
  // 将该文件描述符设置为非阻塞
  fcntl(fd, F_SETFL, fl | O_NONBLOCK);
  return true;
}

注意：

对于一个文件描述符而言，只需要通过 fcntl() 设置一次即可；

如果文件描述符设置为非阻塞，此时 read 时，我们需要通过返回值判定不同的处理方式，比如：

如果返回值 > 0，代表读取成功；
如果返回值 == -1，此时我们需要再次判断，是读取错误，还是底层数据没有就绪呢？

因此，我们需要通过 errno 这个全局变量，判别是读取错误，还是底层数据没有就绪，比如：

如果 errno == 11，即 errno == EWOULDBLOCK，那么代表着底层数据没有就绪，try again 即可；
如果 errno == 4，即 errno == EINTR，代表着此次IO可能被某个信号中断，try again 即可；
如果是其他错误码，进行差错处理。

简单实现一个，非阻塞轮询式IO，实现如下：

#include <iostream>
#include <cstring>
#include <unistd.h>
#include <fcntl.h>

bool SetNonBlock(int fd)
{
  // 步骤一
  // 通过F_GETFL获取当前fd对应的文件状态标志
  // 可以将该文件状态标志(fl)理解为一个位图
  int fl = fcntl(fd, F_GETFL);
  if(fl == -1)
  {
    std::cout << "fcntl error" << std::endl;
    return false;
  }

  // 步骤二
  // 获取文件描述符的文件状态标志成功后
  // 将该文件描述符设置为非阻塞
  fcntl(fd, F_SETFL, fl | O_NONBLOCK);
  return true;
}

int main()
{
  // 众所周知, 从0号文件描述符读取内容默认是以阻塞方式进行的
  // 但我们可以通过 fcntl 系统调用设置非阻塞IO
  if(!SetNonBlock(0)) exit(1);
  // 只需要设置一次即可
  // 后续的0号文件描述符就是非阻塞的
  
  char buffer[1024] = {0};
  while(true)
  {
    sleep(1);
    errno = 0;
    ssize_t real_size = read(0, buffer, sizeof buffer - 1);
    if(real_size > 0)
    {
      buffer[real_size] = 0;
      std::cout << "echo: " << buffer << "errno: " << errno << " errnoMessage: " << strerror(errno) << std::endl;
    }
    else
    {
      if(errno == EAGAIN || errno == EWOULDBLOCK)
      {
        // #define EWOULDBLOCK EAGAIN
        // #define EAGAIN 11
        // 当errno == 11时, 其实并没有错, 只不过底层数据没就绪, 再试一次吧~~~~
        std::cout << "Resource temporarily unavailable, Try again" << std::endl;
        continue;
      }
      else if(errno == EINTR)
      {
        // 此时也并不代表有错, 此次IO可能被某个信号中断了, Try again
        std::cout << "IO operation was interrupted by a signal, Try again" << std::endl;
        continue;
      }
      else
      {
        // 其他错误, 差错处理即可
        std::cout << "other error" << std::endl;
        exit(2);
      }
    }
  }
  return 0;
}