1.线程
1.1.怎么理解线程
什么是线程?跟进程怎么感觉好类似??它们什么关系啊?
先来复习一下
需要明确的是,一个进程的创建实际上伴随着其进程控制块(task_struct)、进程地址空间(mm_struct)以及页表的创建,虚拟地址和物理地址就是通过页表建立映射的。
每个进程都有自己独立的进程地址空间和独立的页表,也就意味着所有进程在运行时本身就具有独立性。
我们一个进程的时候是通过进程地址空间来看自己的资源的,地址空间是进程的资源窗口。
我们讲过,cpu调度我们这个进程,就是把我们的task_struct加入到cpu的运行队列上面去。
如果我想再创建1个子进程,操作系统会怎么做?
- 操作系统会另外创建task_struct,mm_struct,页表,映射到不同的物理内存, 每个进程都具有独立性!!!包括它的内核数据结构。
但如果我们在创建“进程”时,只创建task_struct,并要求创建出来的task_struct和父进程的task_struct共享进程地址空间和页表,那么创建的结果就是下面这样的:
此时我们创建的实际上就是四个线程:
线程是在进程的进程地址空间里面运行,那为什么,如何理解?
- 任何执行流要执行,必须得有资源,没有资源都跑不起来,比如屏幕,代码
- 而进程地址空间是进程的资源窗口,资源就在这里
- 所以线程就得在进程地址空间运行!!
- 其中每一个线程都是当前进程里面的一个执行流,也就是我们常说的“线程是进程内部的一个执行分支”。
- 同时我们也可以看出,线程在进程内部运行,本质就是线程在进程地址空间内运行,也就是说曾经这个进程申请的所有资源,几乎都是被所有线程共享的。
- 线程的执行粒度比进程要细?——因为线程执行进程代码的一部分
注意: 单纯从技术角度,这个是一定能实现的,因为它比创建一个原始进程所做的工作更轻量化了。
我们讲进程调度的时候,task_struct去运行队列里面排队,那么cpu进行进程调度的时候,知不知道这个排队的task_struct是进程的还是线程的?
- 不需要知道
- cpu只有调度执行流的概念,它不需要了解这些!
- 线程(真正的线程)<=执行流<=进程
现在我们可以给线程下定义了
线程是操作系统调度的基本单位。
在一个程序里的一个执行路线就叫做线程(thread)。更准确的定义是:线程是“一个进程内部的控制序列”。
- 一切进程至少都有一个执行线程。
- 线程在进程内部运行,本质是在进程地址空间内运行。
- 在Linux系统中,在CPU眼中,看到的PCB都要比传统的进程更轻量化。
- 透过进程虚拟地址空间,可以看到进程的大部分资源,将进程资源合理分配给每个执行流,就形成了线程执行流。
有人说线程是操作系统调度的基本单位,那我们该如何重新理解之前的进程?
下面用蓝色方框框起来的内容,我们将这个整体叫做进程。
因此,所谓的进程并不是通过task_struct来衡量的,除了task_struct之外,一个进程还要有进程地址空间、文件、信号等等,合起来称之为一个进程。
现在我们应该站在内核角度来理解进程:承担分配系统资源的基本实体,叫做进程。
换言之,当我们创建进程时是创建一个task_struct、创建地址空间、维护页表,然后在物理内存当中开辟空间、构建映射,打开进程默认打开的相关文件、注册信号对应的处理方案等等。
好了,该讲正题!!
我们以前理解的进程,就是操作系统以进程为单位给我们分配资源,只不过我们这个进程只有1个执行流,是进程的一种特殊情况
反之,内部有多个执行流的进程叫做多执行流进程,就会分配多个进程task_struct。
我们现在再来理解之前的一个问题,在Linux中,站在CPU的角度,能否识别当前调度的task_struct是进程还是线程?
答案是不能,也不需要了,因为CPU只关心一个一个的独立执行流。无论进程内部只有一个执行流还是有多个执行流,CPU都是以task_struct为单位进行调度的。
单执行流进程被调度:
多执行流进程被调度:
因此,CPU看到的虽说还是task_struct,但已经比传统的进程要更轻量化了。
Linux下并不存在真正的多线程!而是用进程模拟的!
操作系统中存在大量的进程,一个进程内又存在一个或多个线程,因此线程的数量一定比进程的数量多,当线程的数量足够多的时候,很明显线程的执行粒度要比进程更细。
如果一款操作系统要支持真的线程,那么就需要对这些线程进行管理。比如说创建线程、终止线程、调度线程、切换线程、给线程分配资源、释放资源以及回收资源等等,所有的这一套相比较进程都需要另起炉灶,搭建一套与进程平行的线程管理模块。
因此,如果要支持真的线程一定会提高设计操作系统的复杂程度。在Linux看来,描述线程的控制块和描述进程的控制块是类似的,因此Linux并没有重新为线程设计数据结构,而是直接复用了进程的内核数据结构,所以我们说Linux中的所有执行流(线程和进程)都叫做轻量级进程。
但也有支持真的线程的操作系统,比如Windows操作系统,因此Windows操作系统系统的实现逻辑一定比Linux操作系统的实现逻辑要复杂得多。
重新理解进程和线程的关系
在一个家庭里,有很多人,每个成员都有不同的任务比如家长就赚钱,小孩子就好好读书,爷爷奶奶就好好养老,这样子做的目的都是为了把日子过好。家里的沙发啊,凳子,空调……是家庭的资源,大家可以一起使用
进程相当于一个家庭,线程相当于家庭里的每个成员。线程有不同的任务,执行好了,进程的运行状况也就好了 ,家里的沙发啊,凳子,空调……相当于进程的其他资源,每个进程可以一起使用
当然也有只有1个人的家庭,家里的所有东西都是他的,他努力也是为了把日子过好。进程相当于一个家庭,线程相当于家庭里的这唯一一个成员。自然进程的所有资源也是为它一个线程所用
那么就很好理解,创建1个进程在干什么呢?
- 我们就可以类比上面家庭,成员的例子了,创建1个进程类比创建1个家庭。
摧毁一个进程在干什么呢?
- 就把它的资源全拿走,线程杀掉
线程分配资源的本质,本质就是分配地址空间范围
既然在Linux没有真正意义的线程,那么也就绝对没有真正意义上的线程相关的系统调用!
这很好理解,既然在Linux中都没有真正意义上的线程了,那么自然也没有真正意义上的线程相关的系统调用了。但是Linux可以提供创建轻量级进程的接口,也就是创建进程,共享空间,其中最典型的代表就是vfork函数。
vfork函数的功能就是创建子进程,但是父子共享空间,vfork的函数原型如下:
pid_t vfork(void);
vfork函数的返回值与fork函数的返回值相同:
- 给父进程返回子进程的PID。
- 给子进程返回0。
只不过vfork函数创建出来的子进程与其父进程共享地址空间
例如在下面的代码中,父进程使用vfork函数创建子进程,子进程将全局变量g_val由100改为了200,父进程休眠3秒后再读取到全局变量g_val的值。
#include <stdio.h>
#include <stdlib.h>
#include <sys/types.h>
#include <unistd.h>
int g_val = 100;
int main()
{
pid_t id = vfork();
if (id == 0){
//child
g_val = 200;
printf("child:PID:%d, PPID:%d, g_val:%d\n", getpid(), getppid(), g_val);
exit(0);
}
//father
sleep(3);
printf("father:PID:%d, PPID:%d, g_val:%d\n", getpid(), getppid(), g_val);
return 0;
}
可以看到,父进程读取到g_val的值是子进程修改后的值,也就证明了vfork创建的子进程与其父进程是共享地址空间的。
原生线程库pthread
在Linux中,站在内核角度没有真正意义上线程相关的接口,但是站在用户角度,当用户想创建一个线程时更期望使用thread_create这样类似的接口,而不是vfork函数,因此系统为用户层提供了原生线程库pthread。
原生线程库实际就是对轻量级进程的系统调用进行了封装,在用户层模拟实现了一套线程相关的接口。
因此对于我们来讲,在Linux下学习线程实际上就是学习在用户层模拟实现的这一套接口,而并非操作系统的接口。
1.2.重谈地址空间——二级页表
先复习一下我们的进程的内核数据结构
如何理解线程的资源是怎么分配的??
cpu有1个寄存器CR3,保留了页表的地址
我们知道我们的物理地址被分配为n块4kb大小的块的,也就是4*1024
虚拟地址是如何转换到物理地址的?
以32位平台为例,在32位平台下一共有232个地址,也就意味着有232个地址需要被映射。
如果我们所谓的页表就只是单纯的一张表,那么这张表就需要建立232个虚拟地址和物理地址之间的映射关系,即这张表一共有232个映射表项。
每一个表项中除了要有虚拟地址和与其映射的物理地址以外,实际还需要有一些权限相关的信息,比如我们所说的用户级页表和内核级页表,实际就是通过权限进行区分的。
每个应表项中存储一个物理地址和一个虚拟地址就需要8个字节,考虑到还需要包含权限相关的各种信息,这里每一个表项就按10个字节计算。
这里一共有232个表项,也就意味着存储这张页表我们需要用232 * 10个字节,也就是40GB。而在32位平台下我们的内存可能一共就只有4GB,也就是说我们根本无法存储这样的一张页表。
因此所谓的页表并不是单纯的一张表。
还是以32位平台为例,其页表的映射过程如下:
- 选择虚拟地址的前10个比特位在页目录当中进行查找,找到对应的页表。
- 再选择虚拟地址的10个比特位在对应的页表当中进行查找,找到物理内存中对应页框的起始地址。
- 最后将虚拟地址中剩下的12个比特位作为偏移量从对应页框的起始地址处向后进行偏移,找到物理内存中某一个对应的字节数据。
相关说明:
- 物理内存实际是被划分成一个个4KB大小的页框的,而磁盘上的程序也是被划分成一个个4KB大小的页帧的,当内存和磁盘进行数据交换时也就是以4KB大小为单位进行加载和保存的。
- 4KB实际上就是个字节,也就是说一个页框中有个字节,而访问内存的基本大小是1字节,因此一个页框中就有个地址,于是我们就可以将剩下的12个比特位作为偏移量,从页框的起始地址处开始向后进行偏移,从而找到物理内存中某一个对应字节数据。
这实际上就是我们所谓的二级页表,其中页目录项是一级页表,页表项是二级页表。
每一个表项还是按10字节计算,页目录和页表的表项都是210个,因此一个表的大小就是210 * 10个字节,也就是10KB。而页目录有210个表项也就意味着页表有210个,也就是说一级页表有1张,二级页表有210张,总共算下来大概就是10MB,内存消耗并不高,因此Linux中实际就是这样映射的。
上面所说的所有映射过程,都是由MMU(MemoryManagementUnit)这个硬件完成的,该硬件是集成在CPU内的。页表是一种软件映射,MMU是一种硬件映射,所以计算机进行虚拟地址到物理地址的转化采用的是软硬件结合的方式。
注意: 在Linux中,32位平台下用的是二级页表,而64位平台下用的是多级页表。
修改常量字符串为什么会触发段错误?
当我们要修改一个字符串常量时,虚拟地址必须经过页表映射找到对应的物理内存,而在查表过程中发现其权限是只读的,此时你要对其进行修改就会在MMU内部触发硬件错误,操作系统在识别到是哪一个进程导致的之后,就会给该进程发送信号对其进行终止。
1.3.线程的优点
- 创建一个新线程的代价要比创建一个新进程小得多。
- 与进程之间的切换相比,线程之间的切换需要操作系统做的工作要少很多。
- 线程占用的资源要比进程少很多。
- 能充分利用多处理器的可并行数量。
- 在等待慢速IO操作结束的同时,程序可执行其他的计算任务。
- 计算密集型应用,为了能在多处理器系统上运行,将计算分解到多个线程中实现。
- IO密集型应用,为了提高性能,将IO操作重叠,线程可以同时等待不同的IO操作。
概念说明:
- 计算密集型:执行流的大部分任务,主要以计算为主。比如加密解密、大数据查找等。
- IO密集型:执行流的大部分任务,主要以IO为主。比如刷磁盘、访问数据库、访问网络等。
1.4.线程的缺点
- 性能损失: 一个很少被外部事件阻塞的计算密集型线程往往无法与其他线程共享同一个处理器。如果计算密集型线程的数量比可用的处理器多,那么可能会有较大的性能损失,这里的性能损失指的是增加了额外的同步和调度开销,而可用的资源不变。
- 健壮性降低: 编写多线程需要更全面更深入的考虑,在一个多线程程序里,因时间分配上的细微偏差或者因共享了不该共享的变量而造成不良影响的可能性是很大的,换句话说,线程之间是缺乏保护的。
- 缺乏访问控制: 进程是访问控制的基本粒度,在一个线程中调用某些OS函数会对整个进程造成影响。
- 编程难度提高: 编写与调试一个多线程程序比单线程程序困难得多。
1.5.线程异常
- 单个线程如果出现除零、野指针等问题导致线程崩溃,进程也会随着崩溃。
- 线程是进程的执行分支,线程出异常,就类似进程出异常,进而触发信号机制,终止进程,进程终止,该进程内的所有线程也就随即退出。
1.6.线程用途
- 合理的使用多线程,能提高CPU密集型程序的执行效率。
- 合理的使用多线程,能提高IO密集型程序的用户体验(如生活中我们一边写代码一边下载开发工具,就是多线程运行的一种表现)。
2.Linux进程VS线程
线程为什么比进程更轻量化?
- 创建和释放更加轻量化
- 切换更加轻量化
2.1.进程和线程
进程是承担分配系统资源的基本实体,线程是调度的基本单位。
线程共享进程数据,但也拥有自己的一部分数据:
- 线程ID。
- 一组寄存器。(存储每个线程的上下文信息)
- 栈。(每个线程都有临时的数据,需要压栈出栈)
- errno。(C语言提供的全局变量,每个线程都有自己的)
- 信号屏蔽字。
- 调度优先级。
2.2.进程的多个线程共享
一个进程有多个线程。
因为线程都是在同一个地址空间,因此所谓的代码段(Text Segment)、数据段(Data Segment)都是共享的:
- 如果定义一个函数,在各线程中都可以调用。
- 如果定义一个全局变量,在各线程中都可以访问到。
除此之外,各线程还共享以下进程资源和环境:
- 文件描述符表。(进程打开一个文件后,其他线程也能够看到)
- 每种信号的处理方式。(SIG_IGN、SIG_DFL或者自定义的信号处理函数)
- 当前工作目录。(cwd)
- 用户ID和组ID。
2.3.进程和线程的关系
进程和线程的关系如下图: