并发编程之IO模型

主要内容：

　　一、IO模型介绍

　　二、阻塞IO

　　三、非阻塞IO

　　四、多路复用

1?? IO模型介绍

　　1 何为同步、异步、阻塞和非阻塞

　　　  同步：　　　　　

#所谓同步，就是在发出一个功能调用时，在没有得到结果之前，该调用就不会返回。按照这个定义，其实绝大多数函数都是同步调用。但是一般而言，我们在说同步、异步的时候，特指那些需要其他部件协作或者需要一定时间完成的任务。
#举例：
#1. multiprocessing.Pool下的apply #发起同步调用后，就在原地等着任务结束，根本不考虑任务是在计算还是在io阻塞，总之就是一股脑地等任务结束

　　　　异步：

#异步的概念和同步相对。当一个异步功能调用发出后，调用者不能立刻得到结果。当该异步功能完成后，通过状态、通知或回调来通知调用者。如果异步功能用状态来通知，那么调用者就需要每隔一定时间检查一次，效率就很低（有些初学多线程编程的人，总喜欢用一个循环去检查某个变量的值，这其实是一 种很严重的错误）。如果是使用通知的方式，效率则很高，因为异步功能几乎不需要做额外的操作。至于回调函数，其实和通知没太多区别。
#举例：
#1. multiprocessing.Pool().apply_async() #发起异步调用后，并不会等待任务结束才返回，相反，会立即获取一个临时结果（并不是最终的结果，可能是封装好的一个对象）。

　　　　阻塞：

#阻塞调用是指调用结果返回之前，当前线程会被挂起（如遇到io操作）。函数只有在得到结果之后才会将阻塞的线程激活。有人也许会把阻塞调用和同步调用等同起来，实际上他是不同的。对于同步调用来说，很多时候当前线程还是激活的，只是从逻辑上当前函数没有返回而已。
#举例：
#1. 同步调用：apply一个累计1亿次的任务，该调用会一直等待，直到任务返回结果为止，但并未阻塞住（即便是被抢走cpu的执行权限，那也是处于就绪态）;
#2. 阻塞调用：当socket工作在阻塞模式的时候，如果没有数据的情况下调用recv函数，则当前线程就会被挂起，直到有数据为止。

　　　　非阻塞：

#非阻塞和阻塞的概念相对应，指在不能立刻得到结果之前也会立刻返回，同时该函数不会阻塞当前线程。

　　小结：

#1. 同步与异步针对的是函数/任务的调用方式：同步就是当一个进程发起一个函数（任务）调用的时候，一直等到函数（任务）完成，而进程继续处于激活状态。而异步情况下是当一个进程发起一个函数（任务）调用的时候，不会等函数返回，而是继续往下执行当，函数返回的时候通过状态、通知、事件等方式通知进程任务完成。

#2. 阻塞与非阻塞针对的是进程或线程：阻塞是当请求不能满足的时候就将进程挂起，而非阻塞则不会阻塞当前进程

　　2、IO模型分类

　　一般分为五类：

* blocking IO  # 阻塞IO
* nonblocking IO  # 非阻塞IO
* IO multiplexing  # 多路复用
* signal driven IO  # 信号驱动IO
* asynchronous IO  # 异步IO

# signal driven IO（信号驱动IO）在实际中并不常用，所以主要介绍其余四种IO Model。

　　IO发生时涉及的对象和步骤：

　　　以read为例，它主要涉及两个系统对象，一个调用这个IO的process \(or thread\)，另一个就是系统内核\(kernel\)。

　　当一个read操作发生时，该操作会经历两个阶段：

1）等待数据准备 (Waiting for the data to be ready)
2）将数据从内核拷贝到进程中(Copying the data from the kernel to the process)

2?? 阻塞IO（blocking IO ）

　　在linux中，默认情况下所有的socket都是blocking，一个典型的读操作流程大概是这样：

　　      当用户进程调用了recvfrom这个系统调用，kernel就开始了IO的第一个阶段：准备数据。

　　对于network io来说，很多时候数据在一开始还没有到达（比如，还没有收到一个完整的UDP包），

　　这个时候kernel就要等待足够的数据到来。　　　

　　　　而在用户进程这边，整个进程会被阻塞。当kernel一直等到数据准备好了，它就会将数据从kernel中拷贝到用户内存，
　　然后kernel返回结果，用户进程才解除block的状态，重新运行起来。所以，blocking IO的特点就是在IO执行的两个阶段　　（等待数据和拷贝数据两个阶段）都被block了。

几乎所有的程序员第一次接触到的网络编程都是从listen\(\)、send\(\)、recv\(\) 等接口开始的，
使用这些接口可以很方便的构建服务器/客户机的模型。然而大部分的socket接口都是阻塞型的。如下图

ps：
所谓阻塞型接口是指系统调用（一般是IO接口）不返回调用结果并让当前线程一直阻塞
只有当该系统调用获得结果或者超时出错时才返回。

　　　　实际上，除非特别指定，几乎所有的IO接口 ( 包括socket接口 ) 都是阻塞型的。这给网络编程带来了一个很大的问题，

　　如在调用recv(1024)的同时，线程将被阻塞，在此期间，线程将无法执行任何运算或响应任何的网络请求。

　　　　一个简单的解决方案是：　　

在服务器端使用多线程（或多进程）。多线程（或多进程）的目的是让每个连接都拥有独立的线程（或进程），
这样任何一个连接的阻塞都不会影响其他的连接。

　　实例如下：

　　　　分两部分，客户端（client.py）和服务端（server.py）

　　　　client.py

#！/usr/bin/env python3
#-*- coding:utf-8 -*-
# write by congcong
from socket import *

def talk():
    client = socket(AF_INET,SOCK_STREAM)
    client.connect((‘127.0.0.1‘,8806))

    while True:
        mes = input(‘>>>:‘).strip()
        if not mes:continue
        client.send(mes.encode(‘utf-8‘))
        data = client.recv(1024)
        print(data.decode(‘utf-8‘))
    client.close()

if __name__ == ‘__main__‘:
    talk()

　　　　server.py

#！/usr/bin/env python3
#-*- coding:utf-8 -*-
# write by congcong

from socket import *
from threading import Thread,currentThread

def talk(conn):
    while True:
        try:
            data = conn.recv(1024)
            if not data:break
            print(data.decode(‘utf-8‘))
            conn.send((‘%s hello‘%currentThread().getName()).encode(‘utf-8‘))
        except ConnectionResetError:
            break
    conn.close()

def server(ip,port):
    server = socket(AF_INET,SOCK_STREAM)
    server.bind((ip,port))
    server.listen(5)
    while True:
        print(‘staring...‘)
        conn,addres = server.accept()
        print(addres)
        t = Thread(target=talk,args=(conn,))
        t.start()

    server.close()

if __name__ == ‘__main__‘:
    server(‘127.0.0.1‘,8806)

　　但存在问题下述问题：　

   虽然实现了并发，即实际则回避了阻塞的问题（并未解决），思路是：让主线程接收客户端的链接，而当每收到了一个链接，就新建一个线程，负责收发消息，互不影响，并没有监测IO,每个线程遇到阻塞IO时，仍然阻塞，但并不影响其他线程，从而实现并发。但会随着客户端链接的增多，服务端开的线程则越来越多，浪费资源，而为了避免机器崩溃。而设置线程池（适应问题规模较小的情况），限制并发数目，效率降低，但保证了机器健康运行。
 　所以，至此，单线程下的IO阻塞问题仍未解决。

3??  非阻塞IO（nonblocking IO）

　　Linux下，可以通过设置socket使其变为non-blocking。当对一个non-blocking socket执行读操作时，流程是这个样子：

　　对流程图理解如下：

　　当用户进程发出read操作时，如果kernel中的数据还没有准备好，那么它并不会block用户进程，而是立刻返回一个error。从用户进程角度讲 ，它发起一个read操作后，并不需要等待，而是马上就得到了一个结果。用户进程判断结果是一个error时，它就知道数据还没有准备好，于是用户就可以在本次到下次再发起read询问的时间间隔内做其他事情，或者直接再次发送read操作。一旦kernel中的数据准备好了，并且又再次收到了用户进程的system call，那么它马上就将数据拷贝到了用户内存（这一阶段仍然是阻塞的），然后返回。　　

也就是说非阻塞的recvform系统调用调用之后，进程并没有被阻塞，内核马上返回给进程，如果数据还没准备好，此时会返回一个error。进程在返回之后，可以干点别的事情，然后再发起recvform系统调用。重复上面的过程，
循环往复的进行recvform系统调用。这个过程通常被称之为轮询。轮询检查内核数据，直到数据准备好，再拷贝数据到进程，进行数据处理。需要注意，拷贝数据整个过程，进程仍然是属于阻塞的状态。

原文地址：https://www.cnblogs.com/schut/p/9033933.html