博客封面

✨✨所属专栏:Linux✨✨

✨✨作者主页:嶔某✨✨

Linux:线程概念与控制

概念

在一个程序里的一个执行路线就叫做线程thread。更准确一点:线程是“一个进程内部的控制序列”

一切进程都至少有一个线程

线程在进程内部运行,本质是在进程地址空间运行

Linux系统中,在CPU眼中,看到的PCB都要比传统的要轻量化

透过进程虚拟地址空间,可以看到进程的大部分资源,将进程资源合理分配给每个执行流,就形成了线程执行流。

image-20250408221044041

分页式储存管理

如果没有虚拟内存和分页机制,每一个用户在物理内存上的空间必须是连续的,如下图

8b127986cf552877b7077b3a82fedaa

因为每一个程序的代码、数据长度都是不一样的,按照这样的映射方式,物理内存会被分成各种离散的大小不同的块。有些程序会退出,它们占据的物理内存会被回收,一段时间过后,物理内存就变得非常碎片化,不易管理了。

所以我们希望操作系统给用户的空间是连续的,但是物理内存最好不要连续,那么虚拟内存和分页就出现了。

image-20250409223428641

把物理内存按照一个固定的长度页框进行分割,叫做物理页。每一个页框包含一个物理页page。页的大小就是页框的大小。32位机器支持4kb的页,64位机器支持8kb的页。

有了这种机制,CPU并非直接访问物理地址,而是通过虚拟地址空间来间接的访问物理内存地址。所谓的虚拟地址空间,是操作系统位每一个在执行的进程分配的一个逻辑地址,32位机器上其范围为0-4GB

操作系统通过将虚拟地址空间与物理地址间建立映射关系:页表,这张表上记录了每一对页和页框的映射关系,能让CPU间接访问物理内存地址。

其思想就是**将虚拟内存下的逻辑地址空间分为若干的页,将物理内存空间分为若干页框,通过页表将连续的虚拟内存,映射到若干个不连续的物理内存页。**这样就解决了使用连续的物理内存造成的碎片问题。

物理内存管理

假设一个可用的物理内存有4GB的空间。按照一个页框的大小4KB划分,4GB的空间就是4GB/4KB = 1048576个页框。有这么多的物理页,操作系统肯定是要对它们进行管理的,OS要知道哪些页被使用,哪些页在空闲。

Linux内核里面使用了struct page结构描述系统中的每个物理页,为了节省内存(这个结构体本身也是在内核,也是在内存里面的)这里面使用了大量的联合体union

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
/* include/linux/mm_types.h */
struct page
{
/* 原⼦标志,有些情况下会异步更新 */
unsigned long flags;
union
{
struct
{
/* 换出⻚列表,例如由zone->lru_lock保护的active_list */
struct list_head lru;
/* 如果最低为为0,则指向inode
* address_space,或为NULL
* 如果⻚映射为匿名内存,最低为置位
* ⽽且该指针指向anon_vma对象
*/
struct address_space *mapping;
/* 在映射内的偏移量 */
pgoff_t index;
/*
* 由映射私有,不透明数据
* 如果设置了PagePrivate,通常⽤于buffer_heads
* 如果设置了PageSwapCache,则⽤于swp_entry_t
* 如果设置了PG_buddy,则⽤于表⽰伙伴系统中的阶
*/
unsigned long private;
};
struct
{ /* slab, slob and slub */
union
{
struct list_head slab_list; /* uses lru */
struct
{ /* Partial pages */
struct page *next;
#ifdef CONFIG_64BIT
int pages; /* Nr of pages left */
int pobjects; /* Approximate count */
#else
short int pages;
short int pobjects;
#endif
};
};
struct kmem_cache *slab_cache; /* not slob */
/* Double-word boundary */
void *freelist; /* first free object */
union
{
void *s_mem; /* slab: first object */
unsigned long counters; /* SLUB */
struct
{ /* SLUB */
unsigned inuse : 16; /* ⽤于SLUB分配器:对象的数⽬ */
unsigned objects : 15;
unsigned frozen : 1;
};
};
};
...
};
union
{
/* 内存管理⼦系统中映射的⻚表项计数,⽤于表⽰⻚是否已经映射,还⽤于限制逆向映射搜索*/
atomic_t _mapcount;
unsigned int page_type;
unsigned int active; /* SLAB */
int units; /* SLOB */
};
...
#if defined(WANT_PAGE_VIRTUAL)
/* 内核虚拟地址(如果没有映射则为NULL,即⾼端内存) */
void *virtual;
#endif /* WANT_PAGE_VIRTUAL */
...
}

重要参数

  1. flags:用来存放页的状态。包括是不是脏的,是不是被锁定在内存中等等。flags的每一位单独表示一种状态,所以他至少可以同时表示出32种不同的状态。这些标志定义在<linux/page-flags.h>中。其中⼀些比特位非常重要,如PG_locked⽤于指定页是否锁定,PG_uptodate⽤于表示页的数据已经从块设备读取并且没有出现错误。
  2. _mapcount:表示在页表中有多少项指向该页,也就是这一页被引⽤了多少次。当计数值变为-1时,就说明当前内核并没有引⽤这一页,于是在新的分配中就可以使用它。
  3. virtual:是页的虚拟地址。通常情况下,它就是页在虚拟内存中的地址。有些内存(即所谓的⾼端内存)并不永久地映射到内核地址空间上。在这种情况下,这个域的值为NULL,需要的时候,必须动态地映射这些页。

要注意的是struct page与物理页相关,⽽并非与虚拟页相关。⽽系统中的每个物理页都要分配⼀个这样的结构体,让我们来算算对所有这些页都这么做,到底要消耗掉多少内存。

struct page占40个字节的内存吧,假定系统的物理页为 4KB ⼤⼩,系统有 4GB 物理内存。那么系统中共有页面 1048576 个(1兆个),所以描述这么多⻚⾯的page结构体消耗的内存只不过40MB ,相对系统 4GB 内存而言,仅是很小的⼀部分罢了。因此,要管理系统中这么多物理⻚⾯,这个代价并不算太大。

要知道的是,页的大小对于内存利⽤和系统开销来说非常重要,页太大,页必然会剩余较⼤不能利⽤的空间(页内碎片)。页太小,虽然可以减小页内碎片的大小,但是页太多,会使得页表太长而占⽤内存,同时系统频繁地进行页转化,加重系统开销。因此,页的大小应该适中,通常为 512B -8KBwindows系统的页框大小为4KB

页表

页表中的每一个表项都指向一个物理页的起始地址。在32位机器上要将4GB的空间全部用页表指向的话需要4GB/4KB = 1048576个表项。

页表中的物理地址,和真实的物理页之间是随机映射关系,哪里可用就指向哪里。**最终使用的物理内存是离散的,但是虚拟地址是连续的。**处理器在访问数据、获取指令都是用的虚拟地址,最终都能通过页表找到物理地址。

我们可以算一下,在32位机器上,地址长度为4字节,页表占用的空间为1048576 * 4 = 4MB,映射页表本身就要消耗4MB / 4KB = 1024个物理页。每次新起一个进程,都要将这占用了1024个物理页的页表加载映射到内存,但是根据局部性原理,一个进程在一段时间内只需要访问某几个页就可以正常运行了。所以根本没有必要将所有的物理页都常驻内存。

解决这一问题的方法就是对页表再次分页,即多级页表。

我们将单一的一个页表再次拆分为1024个更小的映射表。1024(每个表中的表项数)* 1024(表的个数)仍然可以覆盖4GB的物理内存空间。

image-20250415173654528

这里的每一个页表就是真正的页表了,一共有1024个页表,一个页表占用4KB,一共也就是4MB。虽然和之前没区别,但是一个应用程序不可能把这些页表全部用完的,这样设计方便用多少,开多少。例如:一个程序的代码段、数据段、栈、一共只需要10MB的空间,那么使用3个页表就够用了。(一个页表能覆盖4MB的物理空间)

页目录结构

那么每一个页框都有一个页表项来指向,这1024个页表也需要被管理起来。管理页表的表称为页目录表,形成了二级页表:

image-20250415174355634

所有页表的物理地址都被页目录表指向

页目录的物理地址被CR3寄存器指向,此寄存器保存了当前正在执行任务的页目录地址。

所以在程序被加载的时候,不仅要为程序的内容分配物理内存,还需要为保存程序物理地址和虚拟地址映射的页目录和页表分配物理内存。

两级页表的地址转换

下面以一个逻辑地址为例。将逻辑地址0000000000,0000000001,111111111111转化为物理地址的过程:

  1. 在32为处理器中,采用4KB页大小,则虚拟地址中的低12为为页偏移,剩下的高20位给页表分成两级,每个级占10位。
  2. CR3寄存器读取页目录起始地址,再根据一级页号查页目录表,找到下一级页表在物理内存中存放位置。
  3. 根据二级页号查表,找到最终想要访问的内存块号。
  4. 结合页内偏移量得到物理地址。

image-20250415175946257

那么这个工作流就没有缺点了吗?当然是有的!MMU进行两次查询确定物理地址,在确认了权限问题后,将这个物理地址发到总线,内存收到后开始读取数据并返回。当页表变为N级时需要经过N次检索+1次读写,查询效率就会变低。

那么有没有提升效率的方法呢?有的,那就是添加一层中间层也就是TLB江湖人称“快表”,其实也就是缓存。当 CPUMMU 传新虚拟地址之后, MMU 先去问 TLB 那边有没有,如果有就直接拿到物理地址发到总线给内存,⻬活。但 TLB 容量比较小,难免发生 Cache Miss ,这时候 MMU 还有保底的⽼武器页表,在页表中找到之后 MMU 除了把地址发到总线传给内存,还把这条映射关系给到TLB,让它记录⼀下刷新缓存。

image-20250415180831926

缺页异常

设想,CPUMMU 的虚拟地址,在 TLB 和页表都没有找到对应的物理页,该怎么办呢?其实这就是缺页异常 Page Fault ,它是⼀个由硬件中断触发的可以由软件逻辑纠正的错误。假如目标内存页在物理内存中没有对应的物理页或者存在但⽆对应权限,CPU 就⽆法获取数据,这种情况下CPU就会报告⼀个缺页错误。由于 CPU 没有数据就无法进行计算,CPU罢工了用户进程也就出现了缺页中断,进程会从用户态切换到内核态,并将缺页中断交给内核的 Page Fault Handler 处理。

image-20250415181131773

缺页中断会交给PageFaultHandler处理,其根据缺页中断的不同类型进行不同的处理:

Linux进程VS线程

线程优点

线程缺点

⼀个很少被外部事件阻塞的计算密集型线程往往⽆法与其它线程共享同⼀个处理器。如果计算密集型线程的数量比可用的处理器多,那么可能会有较大的性能损失,这里的性能损失指的是增加了额外的同步和调度开销,而可⽤的资源不变。

编写多线程需要更全⾯更深入的考虑,在⼀个多线程程序⾥,因时间分配上的细微偏差或者因共享了不该共享的变量⽽造成不良影响的可能性是很大的,换句话说线程之间是缺乏保护的。

进程是访问控制的基本粒度,在⼀个线程中调⽤某些OS函数会对整个进程造成影响。

编写与调试⼀个多线程程序比单线程程序困难得多

线程异常

用途

进程和线程

进程的多个线程共享

同⼀地址空间,因此Text SegmentData Segment都是共享的,如果定义⼀个函数,在各线程中都可以调⽤,如果定义⼀个全局变量,在各线程中都可以访问到,除此之外,各线程还共享以下进程资源和环境:

进程和线程的关系如下图:

image-20250415230714478

对于之前学习的进程和这个线程是相悖的吗?并不是,进程就可以看作一个有一个线程执行流的进程。

Linux线程控制

POSIX线程库

创建线程

1
2
3
4
5
6
7
8
9
功能:创建⼀个新的线程
原型:
int pthread_create(pthread_t *thread, const pthread_attr_t *attr, void *(*start_routine)(void*), void *arg);
参数:
thread:返回线程ID
attr:设置线程的属性,attr为NULL表示使用默认属性
start_routine:是个函数地址,线程启动后要执行的函数
arg:传给线程启动函数的参数
返回值:成功返回0;失败返回错误码

错误检查:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
#include <unistd.h>
#include <stdlib.h>
#include <stdio.h>
#include <string.h>
#include <pthread.h>
void *rout(void *arg) {
int i;
for( ; ; ) {
printf("I'am thread 1\n");
sleep(1);
}
}
int main( void )
{
pthread_t tid;
int ret;
if ( (ret=pthread_create(&tid, NULL, rout, NULL)) != 0 ) {
fprintf(stderr, "pthread_create : %s\n", strerror(ret));
exit(EXIT_FAILURE);
}
int i;
for(; ; ) {
printf("I'am main thread\n");
sleep(1);
}
}
1
2
3
#include <pthread.h>
// 获取线程ID
pthread_t pthread_self(void);

这个函数返回pthread_t类型的值,指代的是调用pthread_self函数的线程id。这个idpthread库给每个线程定义的进程内唯一标识,是pthread库维持的。没错,在内核层面根本没有“线程”这个概念,有的只是进程,只是PCB其它的东西都是库给我们封装的。Linux下是根据进程PCB重复利用,搞成了线程,windows下则是另起炉灶,搞出来了一套新的东西。

由于每个进程都有自己独立的内存空间,故这个id的作用域是进程级的而不是系统级(内核不认识)

其实pthread库中也是通过内核提供的系统调用clone...来创建线程的,而内核会为每个线程创建系统全局唯一的id来唯一标识这个线程。

我们可以使用PS命令查看线程信息:

1
2
3
4
5
6
$ ps -aL | head -1 && ps -aL | grep mythread
PID LWP TTY TIME CMD
2711838 2711838 pts/235 00:00:00 mythread
2711838 2711839 pts/235 00:00:00 mythread

-L 选项:打印线程信息

其中LWP就是真正的线程id可以使用gettid()调用,之前使用 pthread_self 得到的这个数实际上是一个地址,在虚拟地址空间上的一个地址,通过这个地址,可以找到关于这个线程的基本信息,包括线程ID,线程栈,寄存器等属性。

ps -aL 得到的线程ID,有⼀个线程ID和进程ID相同,这个线程就是主线程,主线程的栈在虚拟地址空间的栈上,而其他线程的栈在是在共享区(堆栈之间),因为pthread系列函数都是pthread库提供给我们的。而pthread库是在共享区的。所以除了主线程之外的其他线程的栈都在共享区。

线程终止

如果需要止终止某个线程而不终止整个进程,可以有三种方法:

  1. 从线程函数return。这种方法对主线程不适⽤,从main函数return相当于调用exit
  2. 线程可以调用pthread_exit终止自己。
  3. ⼀个线程可以调用pthread_cancel终止同一进程中的另⼀个线程

pthread_exit函数

1
2
3
4
5
6
7
功能:线程终⽌
原型:
void pthread_exit(void *value_ptr);
参数:
value_ptr:value_ptr不要指向一个局部变量。
返回值:
无返回值,跟进程一样,线程结束的时候无法返回到它的调用者(自身)

注意:pthread_exit函数中的输出型参数指向的内存必须是全局的,或者用malloc在堆上开辟的空间,不能指向在线程函数的栈上分配的空间,因为当其他线程得到这个返回值时,这个线程已经退出,会导致非法访问等内存问题。

pehread_cancel函数

1
2
3
4
5
6
7
8
功能:
取消⼀个执行中的线程
原型:
int pthread_cancel(pthread_t thread);
参数:
thread:线程ID
返回值:
成功返回0; 失败返回错误码

线程等待

已经退出的线程,其地址空间没有被释放,仍然在进程地址空间内占据位置,新起来的线程也需要空间,所以需要回收退出线程的空间。

1
2
3
4
5
6
7
8
9
功能:
等待线程结束
原型:
int pthread_join(pthread_t thread, void **value_ptr);
参数:
thread:线程ID
value_ptr:它指向⼀个指针,后者指向线程的返回值
返回值:
成功返回0; 失败返回错误码

调用该函数的线程将挂起等待,直到要join的线程终止。被join的线程以不同的方法终止,通过pthread_join得到的终止状态时不同的,总结如下:

  1. 如果thread线程通过return返回,value_ptr所指向的单元⾥存放的是thread线程函数的返回值。
  2. 如果thread线程被别的线程调⽤pthread_cancel异常终掉,value_ptr所指向的单元⾥存放的是常数PTHREAD_CANCELED
  3. 如果thread线程是自己调用pthread_exit终⽌的,value_ptr所指向的单元存放的是传给pthread_exit的参数。
  4. 如果对thread线程的终止状态不感兴趣,可以传NULLvalue_ptr参数。

分离线程

默认情况下,新创建的线程是joinable的,线程退出后,需要对其进行pthread_join操作,否则无法释放资源,从而造成系统泄漏。

如果不关心线程的返回值,join是⼀种负担,这个时候,我们可以告诉系统,当线程退出时,自动释放线程资源。

1
int pthread_detach(pthread_t thread);

可以是线程组内对其它线程进行分离,亦可以是线程自己分离

1
pthread_detach(pthread_self());

线程被分离了就不是joinable的了

线程ID及进程地址空间布局

1
pthread_t pthread_self(void);
特征 LWP pthread_self()返回值
作用范围 内核空间(系统级调度) 用户空间(线程库级操作)
唯一性 全局唯一(整个系统) 进程内唯一
数据类型 pid_t(通常为整数) pthread_t(具体实现依赖系统)
获取方式 syscall(SYS_gettid)gettid() pthread_self()
用途 内核调度、系统调用、信号处理 线程库函数参数(如pthread_equal

关于pthread_t的类型,取决于具体实现,对于Linux目前实现的NPTL而言,pthread_t类型的线程ID,本质就是一个进程地址空间上的一个地址。

image-20250418225946403

image-20250418230053962

线程封装

最新线程封装具体参考:

25/Udp/chat/thread.hpp · 钦某/Code - 码云 - 开源中国 (gitee.com)

Code/25/Udp/chat/thread.hpp at master · QinMou000/Code (github.com)

没什么好说的,注意detach的顺序就行,造一次轮子就行了。