线程模型的理解

进程和线程

Linux 按照特权等级，把进程的运行空间分为内核空间和用户空间，一次系统调用可以实现用户态和内核态的切换

线程是调度的基本单位，而进程则是资源拥有的基本单位

用户线程 vs 内核线程

图片引用他人，若存在版权问题，请告知

用户线程

• 运行于用户态的线程，不被内核感知；
• 单个进程中可以多个线程共享进程虚拟地址及全局变量；
• 用户线程也有私有数据，比如栈和寄存器等，这些在上下文切换时也是需要保存的；
• 用户态线程上线文切换只在同一进程中切换当前线程寄存器状态与栈等，并不涉及进程上下文切换；
• 用户态线程需要绑定内核态线程；

内核线程

• 用户态线程需要绑定内核态线程，就决定了，每次创建用户线程需要执行一次系统调用，更新内核中的线程表信息(例如执行一次std::thread)
• 内核线程可以放在多个CPU核心运行，但是一次内核线程调用成本高，为了执行一次系统调用，CPU寄存器首先保存用户态指令位置，然后更新为内核态指令的新位置，最后才是跳转到内核态运行内核任务，系统调用结束后，CPU寄存器恢复原保存的用户态指令位置，然后再切换到用户空间，一次系统调用的过程，发生了两次CPU上下文切换

三种线程模型

下面的x对y(x:y)即x个用户态线程对应y个内核调度实体(Kernel Scheduling Entity，这个是内核分配CPU的对象单位)

• 1:1(一个用户线程对应于一个内核线程)
• M:1(M用户线程对应于一个内核线程)
• M:N(M用户线程对应于N个内核线程)

1. 1:1线程模型，可以有效避免线程上下文切换，弊端在于，线程的扩展有限，毕竟内核线程对系统性能影响较大
2. M:1线程模型，用户线程可扩展，但是对于需要使用内核线程的操作(例如IO操作频繁)会导致正在执行IO操作的用户线程因为内核线程没得以释放从而阻塞住同一进程中的其他线程，同时多个用户线程对于内核是无法感知的，故做不到真正意义上的并行调用，从而无法充分利用多核；
3. M:N线程模型，线程的调度需要由内核态和用户态一起来实现，例如线程间同步需要用户态和内核态共同实现。用户态和内核态的分工合作导致实现该模型非常复杂。linux多线程模型曾经也想使用该模型，但它太复杂，要对内核进行大范围改动，所以还是采用了一对一的模型！

协程的进一步理解

关键因子：用户态线程、用户态调度器、协程队列、上下文切换

其实就是用户态线程的一种调度方式，实现了用户态的上下文切换，配合一个用户态调度器与相应协程队列实现；

上下文切换方面，保存好当前的寄存器状态与栈就可以保存好当前的协程状态了（比如可以把寄存器值压到栈里然后栈和PC、SP存起来），恢复的时候就恢复寄存器值以及PC、SP，新建的时候就给个新的栈空间，运行完了就销毁对应的栈空间。不能用汇编的话就需要那个语言本身支持类似的上下文切换操作，比如python里的generator

有上下文切换的方法之后

在需要切换协程的地方保存当前上下文、恢复调度器协程的上下文

调度器协程选择下一个可以运行的协程——协程队列

调度器协程保存自己的上下文，恢复目标协程的上下文

串起来的话，程序运行入口注册好初始要运行的协程（加到可运行队列里），然后启动调度器协程，一个基本的协程框架就可以跑起来了

之后配合epoll之类的event loop，给协程不同的状态（运行中/可运行/阻塞，其实就很类似线程/进程的状态），调度器根据这些状态选择可运行的协程去运行，就是一个比较能用的协程框架了。

以上说的都是单内核线程下的情况，如果是多内核线程（比如Go的GPM模型），那还需要加一层各个协程到对应内核线程的映射，调度器实现会更复杂一点。