【Linux】线程（一）

统一热红茶

已于 2024-06-16 21:27:28 修改

阅读量552

点赞数 8

分类专栏： Linux 文章标签： linux 运维服务器

于 2024-06-12 21:53:02 首次发布

本文链接：https://blog.csdn.net/2301_78636079/article/details/139636605

版权

Linux 专栏收录该内容

28 篇文章 0 订阅

订阅专栏

谈论之前需要先谈论一些线程的背景知识

其中就有进程地址空间，又是这个让我们又爱又恨的东西。

注意：全篇都是在32位的情况下进行的

背景知识：

地址空间：

说在前边，OS通常分为4个核心模块：执行流管理，文件系统管理，文件管理与IO管理。

在这先要涉及到对内存的管理。

内存：

以下是一张内存与磁盘的形象图。
在这里插入图片描述
在没接触内存管理之前我们通常是认为内存是直接一整块的。
现在我们要知道内存其实不是一整块的，而是分成了一个大数组，数组每个大小4kb！每个4kb叫做页框或页帧。

当然，这个是可以进行更改的，但是需要将OS重新编译一份出来，另外这个数字是由计算机科学家研究出来的。

我们的这个4KB是不是看着很熟悉呢？
4KB也正是磁盘文件与系统进行IO的基本单位。
在OS中的巧合都是精心设计的~

结论：我们磁盘中的可执行程序也是文件，是文件就有对应的inode。我们磁盘中已经天然的按4kb，比如说我们文件存放自己的数据就在datablock[]中，这个就是以4kb进行划分的，所以在进行磁盘IO时，所谓的加载就是把数据块加载到指定的内存块。

那么现在就有一个问题了：当父子进程共享了一个全局变量int类型，进行写时拷贝时是进行4字节的拷贝还是4kb呢？

答案是4kb，这遵循了一个局部性的原则，当你本行的数据被修改，那么下一行会有90的概率也被修改，避免了太多的拷贝，OS也是很忙的。
所以其实我们C语言malloc4字节其实也是申请了4kb，只是我们只能只用4字节（很粗略的理解）
我们的共享内存所以一般也都是申请4096个字节的整倍数…

那么是怎么进行划分的呢，那么多4kb是如何管理的呢？
比如每个内存块被占用了多少，被谁占用了…

所以需要进行管理。
假设我们是4GB，那么大约是一百万个页框，更准确来说是1048576，每个页框都有自己的使用情况。

在这里插入图片描述

最底层使用数组进行管理起来，每个page都有自己对应的下标–>使用对应的下标×4kb == 页框地址。

所以对内存的管理就变为了对数组的增删查改。
那么这个数组大约多大呢？
假设每一份是1byte，那么大约是1mb。
但是实际上一份大约是十几byte。那么就是十几MB就可以管理起来这个数组了。

页表：

真实的页表是什么样子？虚拟地址又是如何转化到物理地址？
在还没有真正接触页表之前，我们通常会这么认为：
在这里插入图片描述
我们先来说一下第二个问题：
我们进行地址的转化是需要与CPU进行配合的。
CPU中接收到虚拟地址+MMU–>物理地址。

再来看一下第二个问题：
我们的虚拟地址有32位，那么每个虚拟地址就有32个比特位。

在这里插入图片描述
其中前十比特位用来索引第一张页表，也就是第一张页表的下标。

那么第一张页表中存放的是什么？
是第二张页表的地址。

在这里插入图片描述
所以中10位也就是第二张页表的索引（下标咯）。

那么后12位代表着什么？
我们想到每个页框的大小为4kb->4096字节->[0, 4095]，而我们的后12位正好也是[0, 4095]，所以我们的低12位就是每个页框的偏移量！

所以我们页表的本质是进行搜索页框！

这种分配方案叫做二级页表，大大减少了内存。

口说无凭，我们计算一下：

首先第一张页表叫做页目录。
存的是第二张页表的地址。
页目录的大小 = 4字节×1024 = 4kb。

第二张页表叫做页表
页表中存的是page的起始地址，
页表大小 = 4字节 × 1024 × 1024 = 4mb。

所以总大小为4mb + 4kb就是页表了！

何况也是按照拉满的进行计算，实际是 <= 这个大小的。

注意：page这个管理内存的数据结构与页表是相辅相成，
它们之间虽然在逻辑上有间接的联系（都是用来管理物理内存的不同方面），但实际上它们的数据内容和直接操作是分离的。

但是我们现在仍然只能获得一个字节的地址，一个int都4个字节，怎么读取一个int的数据呢？
所以需要类型？
汇编会告诉CPU你的对象类型是什么。

所以现在还差一个问题。
当CPU获得虚拟地址时，MMU可以进行运算找到页框。但是这个过程中我们得有页目录的地址啊，才能进一步的运算，地址怎么获得？
在CR系列的寄存器中。
在这里插入图片描述
CR3就负责存页目录的地址。

基于以上理解文件缓冲区与虚拟地址：

文件缓冲区：

文件缓冲区实际上就是从struct page memory这个数组中挑几个page与struct file进行关联，这就是文件缓冲区，至于怎么关联的是依靠字典树，了解一下即可。

虚拟地址：

我们以正文代码段为例：在这里插入图片描述
我们的正文代码实际上是一段范围，如果有20个函数，那我们就可以将正文分成20部分。
是不是很抽象的感觉，没事，我们来好好的捋一捋。
首先我们知道函数是有地址的，是一批代码的入口地址；函数的每一行也都有地址，而我们的函数都是连续的，且编译是以平坦模式的绝对编址，所以最终每个函数都是一个一个连续的代码块。

那么正文就理所当然的可以拆分为20分，本质就是拆分页表，也就是一种资源。

线程：

那么就来看一看一下官方的线程定义：

在进程内部运行，是CPU调度的基本单位。

果然是十分抽象~

linux下的线程：

线程与进程实际上是有密不可分的关系。
所以我们先从进程开始了解线程。

这是我们以前接触的进程：
进程 = 内核数据结构 + 代码和数据
在这里插入图片描述
每一个进程都有属于自己的地址空间与页表，各自有各自的数据。

但是如果我们创建几个没有地址空间，页表与全新代码的进程呢？
在这里插入图片描述

我们将正文代码分为3部分，分别给task_structA B C。
让这3个分别执行代码的一部分，他们共享地址空间，这叫做“linux下的线程”。

所以现在我们知道了定义的第一点：线程在进程内部运行，也就是在地址空间内运行。

与进程的澄清：

进程 = 内核数据结构 + 代码和数据。

也就是说下图这个整体是一个进程。
在这里插入图片描述
而线程是其中一个task_struct与虚拟地址+页表+代码数据（绿色的不是）。

站在OS的视角上，我们可以给进程下一个定义：是承担分配系统资源的实体。

怎么理解？
这就像进程是一个家庭，它有着国家分配的资源；而线程是家庭成员。

爸妈执行上班的代码，孩子执行上学的代码，爷爷奶奶执行养老的代码。
他们为了一个共同的目的，那就是将日子过好。

所以我们之前理解的进程就像是家庭中只有一个成员。

win下的进程：

如果我们要设计线程，那么每个进程可能都有很多线程，有的是被创建，有的被销毁，有的被调度，所以就要被管理。win下的线程就是这样设计的。
它有着一个描述线程的tcb，还有一个将tcb组织起来的数据结构。

struct tcb // thread control bolock
{
	// id 优先级 状态 上下文
	// ...
}

在这里插入图片描述

与linux进行比较：

但是linux并没有这么做，linux选择了复用pcb，因为tcb需要的pcb几乎都已经准备好了，于是用pcb统一表示执行流，这样就不需要单独设计了！

那么哪个OS的做法更优呢？
win：实现了真正的tcb。
linux：复用，用进程来模拟线程。

我们认为Linux更优秀，因为他的代码量少，成本低，健壮性高。

那么当CPU调度时，需要关注task_struct是进程还是线程吗？
答案是不需要的，CPU只关心如何执行，每个task_struct都是一个执行流，他已经包含了自己执行需要的东西。

所以CPU看到的每一个执行流都是 <= 进程的，linux中的线程叫做轻量级进程！

所以现在对于定义的第二点我们也能理解了。

代码：

说了这么久的理论，我们总归还是要回归代码的。
在这里插入图片描述

那么线程如何进行创建？
参数解释：
thread：是线程id。
attr：我们不管，设置为nullptr即可。
start_routine：是我们新线程去执行的函数。
arg：传给函数的参数。

在这里插入图片描述

现象：
在这里插入图片描述
发现只有一个pid。
利用ps | ajx也是如此：

原因在于线程都是在同一个进程内部。

但是我们也可以查到线程：ps -aL 即可
在这里插入图片描述
我们发现有一个叫做LWP的东西，这个其实就是轻量级进程的意思（light weight process），下面的数字是线程的唯一标识符。

我们说过CPU调度时是以线程为单位的，那么就肯定看的是LWP。
其中PID = LWD的那一个线程叫做主线程。

有了多进程为什么还要多线程？

这里主要有3个原因造成。
创建：
进程创建时需要PCB，地址空间，页表，加载代码和数据，还有标准输入输出…成本很高；
但是线程的创建只需要创建一个PCB，指向地址空间即可、
调度：
进程的切换要切换上下文，切换页表…
而线程由于是共享地址空间，所以页表那些东西就不要切换了
死亡：
进程的死亡需要释放PCB，虚拟地址空间，页表…
线程只进行删除对应的PCB即可。

但是对于调度的理解还需要再加深一下：
我们切换页表什么的仅仅修改一下CR3寄存器即可，无非就是修改了几个寄存器，实际上并不会有很大的优势。

不过调度效率高这是事实，这其中与硬件还有密不可分的关系。
答案就在于cache。
在这里插入图片描述
我们的CPU为了调度进程时为了更快的访存效率，往往会存在cache，这其实依据了局部性原因，比如当我们访问第五行时，CPU会把围绕这行代码的高频数据预先加载到cache中，这叫做热数据，当所以PU进行访存时会先在cache中寻找，找到直接拿，找不到在切换cache。
这意味着如果是进程间的切换，对与cache中的数据肯定是用不到的，因为进程具有独立性，所以需要将cache的数据全部替换。
而线程的切换往往对于cache是用的到的，避免了大量的替换，所以效率更高！