线程概念与控制

一、Linux线程概念

1、什么是线程

• 在一个程序里的一个执行路线就叫做线程（thread）。更准确的定义是：线程是“一个进程内部的控制序列”。
• 一切进程至少都有一个执行线程。
• 线程在进程内部运行，本质是在进程地址空间内运行。
• 在Linux系统中，在CPU眼中，看到的PCB都要比传统的进程更轻量化。
• 透过进程虚拟地址空间，可以看到进程的大部分资源，将进程资源合理分配给每个执行流，就形成了线程执行流。

需要明确的是，一个进程的创建实际上伴随着其进程控制块（task_struct）、进程地址空间（mm_struct）以及页表的创建，虚拟地址和物理地址就是通过页表建立映射的。

每个进程都有自己独立的进程地址空间和独立的页表，也就意味着所有进程在运行时本身就具有独立性。

但如果我们在创建“进程”时，只创建task_struct，并要求创建出来的task_struct和父task_struct共享进程地址空间和页表，那么创建的结果就是下面这样的：

此时我们创建的实际上就是四个线程：

• 其中每一个线程都是当前进程里面的一个执行流，也就是我们常说的“线程是进程内部的一个执行分支”。
• 同时我们也可以看出，线程在进程内部运行，本质就是线程在进程地址空间内运行，也就是说曾经这个进程申请的所有资源，几乎都是被所有线程共享的。

注意： 单纯从技术角度，这个是一定能实现的，因为它比创建一个原始进程所做的工作更轻量化了。

该如何重新理解之前的进程？

下面用蓝色方框框起来的内容，我们将这个整体叫做进程。

因此，所谓的进程并不是通过task_struct来衡量的，除了task_struct之外，一个进程还要有进程地址空间、文件、信号等等，合起来称之为一个进程。

现在我们应该站在内核角度来理解进程：承担分配系统资源的基本实体，叫做进程。

换言之，当我们创建进程时是创建一个task_struct、创建地址空间、维护页表，然后在物理内存当中开辟空间、构建映射，打开进程默认打开的相关文件、注册信号对应的处理方案等等。

而我们之前接触到的进程都只有一个task_struct，也就是该进程内部只有一个执行流，即单执行流进程，反之，内部有多个执行流的进程叫做多执行流进程。

在Linux中，站在CPU的角度，能否识别当前调度的task_struct是进程还是线程？
答案是不能，也不需要了，因为CPU只关心一个一个的独立执行流。无论进程内部只有一个执行流还是有多个执行流，CPU都是以task_struct为单位进行调度的。

单执行流进程被调度：

多执行流进程被调度：

因此，CPU看到的虽说还是task_struct，但已经比传统的进程要更轻量化了。

2、Linux 线程 VS 其它平台的线程

Linux下并不存在真正的多线程！而是用进程模拟的！

操作系统中存在大量的进程，一个进程内又存在一个或多个线程，因此线程的数量一定比进程的数量多，当线程的数量足够多的时候，很明显线程的执行粒度要比进程更细。

如果一款操作系统要支持真的线程，那么就需要对这些线程进行管理。比如说创建线程、终止线程、调度线程、切换线程、给线程分配资源、释放资源以及回收资源等等，所有的这一套相比较进程都需要另起炉灶，搭建一套与进程平行的线程管理模块。

因此，如果要支持真的线程一定会提高设计操作系统的复杂程度。在Linux看来，描述线程的控制块和描述进程的控制块是类似的，因此Linux并没有重新为线程设计数据结构，而是直接复用了进程控制块，所以我们说Linux中的所有执行流都叫做轻量级进程（LWP）。

但也有支持真的线程的操作系统，比如Windows操作系统，因此Windows操作系统系统的实现逻辑一定比Linux操作系统的实现逻辑要复杂得多。

Linux 线程 VS 其它平台的线程

Windows 具有真正意义上的线程概念。系统中一定存在着大量的进程，而进程 : 线程 = 1 : n，所以系统也一定存在大量的线程，而且不比进程少，OS 也一定要管理线程，那应该如何管理呢？—— 先描述，再组织。所以，支持真线程的系统一定要先描述线程 TCB（Thread Control Block），其内部一定是 PCB && TCB 共生，系统中已经存在了大量的 PCB，还要存在更大量的 TCB，然后 TCB 还要和 PCB 产生某些关系以证明该线程是该进程内的一个执行流，这样一来 OS 既要进程管理，又要线程管理，就一定会使得该 OS 设计的很复杂，其中在描述 TCB 的时候也一定需要和 PCB 类似的各种属性。

但实际上，可以发现线程和进程一样，也是一种执行流，所以一定的是 PCB 和 TCB 在描述时会存在着大量重复的属性。所以，我们可以看到 Windows 确实存在多线程，只不过代价很大，而 Linux 看到后，无论你是什么线程，同样也是执行流，所以就把进程和线程统一了，所以 Linux Kernel 中就没有线程 TCB 的概念。所以，Windows 在 OS 层面下一定提供了相关线程控制的接口，而 Linux 下虽然设计的更简单了，但它不可能在 OS 层面提供线程控制的相关系统调用接口，最多提供了轻量级进程相关的系统调用接口，如 vfork、clone。实际在应用层 Linux 下有一套系统级别的原生线程库 pthread，原生线程库就是在应用层实现的库。其实 C++、Python 等支持多线程的这些语言是有自己原生写好的线程的，且底层一定是用到下面要讲的 pthread。

vfrok

既然在Linux没有真正意义的线程，那么也就绝对没有真正意义上的线程相关的系统调用！

这很好理解，既然在Linux中都没有真正意义上的线程了，那么自然也没有真正意义上的线程相关的系统调用了。但是Linux可以提供创建轻量级进程的接口，也就是创建进程，共享空间，其中最典型的代表就是vfork函数。

vfork函数的功能就是创建子进程，但是父子共享空间，v函数fork的函数原型如下：

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创建的子进程与其父进程是共享地址空间的。

3、原生线程库pthread

在Linux中，站在内核角度没有真正意义上线程相关的接口，但是站在用户角度，当用户想创建一个线程时更期望使用thread_create这样类似的接口，而不是vfork函数，因此系统为用户层提供了原生线程库pthread。

原生线程库实际就是对轻量级进程的系统调用进行了封装，在用户层模拟实现了一套线程相关的接口。

因此对于我们来讲，在Linux下学习线程实际上就是学习在用户层模拟实现的这一套接口，而并非操作系统的接口。

#include <iostream>
#include <unistd.h>
#include <pthread.h>

// 新线程
void *run(void *args)
{
    while(true)
    {
        std::cout << "new thread, pid: " << getpid() << std::endl;
        sleep(1);
    }
    return nullptr;
}

int main()
{
    std::cout << "我是一个进程: " << getpid() << std::endl;
    pthread_t tid;
    pthread_create(&tid, nullptr, run, (void*)"thread-1");

    // 主线程
    while(true)
    {
        std::cout << "main thread, pid: "<< getpid() << std::endl;
        sleep(1);
    }

    return 0;
}

通过实验结果，我们可以发现，确实有两个执行流，同时他们是同一个进程。

此时，我们可以打开另一个xshell来监控，看看有多少个线程
如果用 ps ajx | head -1 && ps ajx | grep mythread 的方式查，为查进程方式，会查出来只有一个。

正确的应该是 ps -aL | head -1 && ps -aL | grep mythread

之前是 ps ajx 来查看一个进程的相关信息，而现在可以用 ps -aL 来查看轻量级进程，可以发现后者的 PID 是相同的，这就说明两个 mythread 本质是属于一个进程，而每一个线程也需要唯一标识。

LWP：
我们可以看到图中PID旁边的是LWP
所以，LWP 用来标识线程的唯一性，PID 标识进程的唯一性。这里还可以看到的是第一组 PID 和 LWP 的值是相同的，如果进程内部是单执行流时，此时 ps ajx 和 ps -aL 查看时 PID 和 LWP 的值是一样的，所以在多线程之前 PID 和 LWP 的意义是一样的。所以，调度进程 CPU 看的是 LWP，那么也就说明了如果 PID 和 LWP 两个值是相同的，那么对应的 LWP 对应的 ID 就是主线程。当我们杀死新线程时，也会影响主线程，说明它们是共生的。

4、分页式存储管理

（1）虚拟地址和页表的由来

思考一下，如果在没有虚拟内存和分页机制的情况下，每一个用户程序在物理内存上所对应的空间必须是连续的，如下图：

因为每一个程序的代码、数据长度都是不一样的，按照这样的映射方式，物理内存将会被分割成各种离散的、大小不同的块。经过一段运行时间之后，有些程序会退出，那么它们占据的物理内存空间可以被回收，导致这些物理内存都是以很多碎片的形式存在。怎么办呢?我们希望操作系统提供给用户的空间必须是连续的，但是物理内存最好不要连续。此时虚拟内存和分页便出现了，如下图所示：

==把物理内存按照一个固定的长度的页框进行分割，有时叫做物理页。==每个页框包含一个物理页(page)。一个页的大小等于页框的大小。大多数 32位 体系结构支持 4KB 的页，而 64位 体系结构一般会支持 8KB 的页。区分一页和一个页框是很重要的：

• 页框是一个存储区域;
• 而页是一个数据块，可以存放在任何页框或磁盘中。

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

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

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

（2）物理内存管理（先描述，再组织）

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

先描述：
内核用 struct page 结构表示系统中的每个物理页，出于节省内存的考虑，struct page 中使用了大量的联合体union。



其中比较重要的几个参数：

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

要注意的是 struct page 与物理页相关，而并非与虚拟页相关。而系统中的每个物理页都要分配一个这样的结构体，让我们来算算对所有这些页都这么做，到底要消耗掉多少内存。算 struct page 占40个字节的内存吧，假定系统的物理页为 4KB 大小，系统有 4GB 物理内存。那么系统中共有页面 1048576个(1兆个)，所以描述这么多页面的page结构体消耗的内存只不过40MB ，相对系统 4GB 内存而言，仅是很小的一部分罢了。因此，要管理系统中这么多物理页面，这个代价并不算太大。
要知道的是，页的大小对于内存利用和系统开销来说非常重要，页太大，页页必然会剩余较大不能利用的空间(页内碎片)。页太小，虽然可以减小页内碎片的大小，但是页太多，会使得页表太长而占用内存，同时系统频繁地进行页转化，加重系统开销。因此，页的大小应该适中，通常为512B-8KB，windows系统的页框大小为4KB。

再组织：
通过一个数组实现管理

物理内存里malloc的一段空间用来放这个数组，管理所有内存块

因此假设磁盘上有四个数据块，要加载进物理内存
第一步：查这个数组，找到四个没有被用的page，把标志位flag从未使用改成正在使用

第二步：把内存块拷贝进来，此时这个内存块就被占用了
第三步：假如不想要这个内存块了，找到page，拿物理地址直接转换成下标，把flag的标志位清零，就叫被释放了。

（3）页表

页表中的每一个表项，指向一个物理页的开始地址。在 32位系统中，虚拟内存的最大空间是 4GB，
这是每一个用户程序都拥有的虚拟内存空间。既然需要让 4GB 的虚拟内存全部可用，那么页表中就需要能够表示这所有的 4GB 空间，那么就一共需要 4GB/4KB = 1048576 个表项。如下图所示：

虚拟内存看上去被虚线“分割”成一个个单元，其实并不是真的分割，虚拟内存仍然是连续的。这个虚线的单元仅仅表示它与页表中每一个表项的映射关系，并最终映射到相同大小的一个物理内存页上。

页表中的物理地址，与物理内存之间，是随机的映射关系，哪里可用就指向哪里(物理页)。虽然最终使用的物理内存是离散的，但是与虚拟内存对应的线性地址是连续的。处理器在访问数据、获取指令时，使用的都是线性地址，只要它是连续的就可以了，最终都能够通过页表找到实际的物理地址。在 32 位系统中，地址的长度是4个字节，那么页表中的每一个表项就是占用 4 个字节。所以页表占据的总空间大小就是：1048576*4= 4MB 的大小。也就是说映射表自己本身，就要占用 4MB/4KB = 1024 个物理页。这会存在哪些问题呢?

• 回想一下，当初为什么使用页表，就是要将进程划分为一个个页可以不用连续的存放在物理内存中，但是此时页表就需要1024个连续的页框，似乎和当时的目标有点背道而驰了…
• 此外，根据局部性原理可知，很多时候进程在一段时间内只需要访问某几个页就可以正常运行了。因此也没有必要一次让所有的物理页都常驻内存。

解决需要大容量页表的最好方法是:把页表看成普通的文件，对它进行离散分配，即对页表再分页由此形成多级页表的思想。

为了解决这个问题，可以把这个单一页表拆分成 1024 个体积更小的映射表。如下图所示。这样一来，1024(每个表中的表项个数)*1024(表的个数)，仍然可以覆盖 4GB 的物理内存空间。

简单画法：

这里的每一个表，就是真正的页表，所以一共有 1024 个页表。一个页表自身占用 4KB ，那么1024 个页表一共就占用了 4MB 的物理内存空间，和之前没差别啊?从总数上看是这样，但是一个应用程序是不可能完全使用全部的 4GB 空间的，也许只要几十个页表就可以了。例如:一个用户程序的代码段、数据段、栈段，一共就需要 10 MB 的空间，那么使用 3个页表就足够了。

计算过程：

• 每一个页表项指向一个 4KB 的物理页，那么一个页表中 1024 个页表项，一共能覆盖 4MB 的物理内存;
• 么 10MB 的程序，向上对齐取整之后(4MB 的倍数，就是 12 MB)，就需要3个页表就可以了。

（4）页目录结构

到目前为止，每一个页框都被一个页表中的一个表项来指向了，那么这 1024 个页表也需要被管理起来。管理页表的表称之为页目录表，形成二级页表。如下图所示：

• 所有页表的物理地址被页目录表项指向
• 页目录的物理地址被CR3 寄存器指向，这个寄存器中，保存了当前正在执行任务的页目录地址。

所以操作系统在加载用户程序的时候，不仅仅需要为程序内容来分配物理内存，还需要为用来保存程序的页目录和页表分配物理内存。

（5）两级页表的地址转换

下面以一个逻辑地址为例。将逻辑地址(0000000000,0000000001,11111111111)转换为物理地址的过程:

1. 在32位处理器中，采用4KB的页大小，则虚拟地址中低12位为页偏移，剩下高20位给页表，分成两级，每个级别占10个bit(10+10)。
2. CR3 寄存器 读取页目录起始地址，再根据一级页号查页目录表，找到下一级页表在物理内存中存放位置。
3. 根据二级页号查表，找到最终想要访问的内存块号，也就是页框起始地址。
4. 结合页内偏移量得到物理地址。
5. 注:一个物理页的地址一定是 4KB 对齐的(最后的 12 位全部为0)，所以其实只需要记录物理页地址的高 20 位即可。
6. 以上其实就是 MMU 的工作流程。MMU(Memory Manage Únit)是一种硬件电路，其速度很快，主要工作是进行内存管理，地址转换只是它承接的业务之一。
   
   因此结合前面所讲：
   

页框起始地址/4就是存在物理内存的那个数组的下标。

到这里其实还有个问题，MMU要先进行两次页表查询确定物理地址，在确认了权限等问题后，MMU再将这个物理地址发送到总线，内存收到之后开始读取对应地址的数据并返回。那么当页表变为N级时，就变成了N次检索+1次读写。可见，页表级数越多查询的步骤越多，对于CPU来说等待时间越长，效率越低。

让我们现在总结一下：单级页表对连续内存要求高，于是引入了多级页表，但是多级页表也是一把双刃剑，在减少连续存储要求且减少存储空间的同时降低了查询效率。
有没有提升效率的办法呢?

（i）TLB

计算机科学中的所有问题，都可以通过添加一个中间层来解决。 MMU 引入了新武器，江湖人称快表的TLB(其实，就是缓存)
当CPU 给 MMU传新虚拟地址之后，MMU 先去问 TLB 那边有没有，如果有就直接拿到物理地址发到总线给内存，齐活。但 TLB 容量比较小，难免发生 Cache Miss ，这时候 MMU 还有保底的老武器页表，在页表中找到之后 MMU 除了把地址发到总线传给内存，还把这条映射关系给到TLB，让它记录一下刷新缓存，也就是缓存了虚拟到物理的历史记录。

再谈MMU：
MMU 1. 需要知道当前进程所对应的页表，通过CR3，里面存的是当前页目录起始地址 2.需知道虚拟地址入口，通过EIP这个寄存器记录。通过这两个就可以转成得知虚拟地址。然后MMU就把得到的物理地址放入总线当中，就会在物理内存进行寻址。

物理内存里也存在两个寄存器，一个放地址，一个放CPU的操作需求是in/out。通过总线流到了第一个寄存器里，内存就拿到了地址，然后如果再读指令，out，那么下一条指令地址就流到EIP，IR里放指令内容，再传给MMU。

补充：
线程切换不需要更新TLB，公共函数、全局变量，TLB里的映射可以共享起来。
进程切换需要更新TLB，进程一旦切换，代码全变了，需要重新建立映射。

（6）缺页异常

讲缺页中断这个异常前，先预备一下各个知识点：
先来讲讲页表的标志位：

第一个标记位是否命中：这个页框在不在内存里，可能就需要执行从外设重新搬进来，需要在虚拟和物理地址之间重新建立映射。
RWX：就是读写执行权限。
U/K就是用户区和内核区的切换。

MMU与这个标记位的关联：

有这样这个代码。hello bit 这个代码会编到字符常量区，实际上会和代码编到一块，这是禁止修改的，下面修改了他，就直接报错崩溃了。问题是他为什么会崩溃呢？

因为在进行虚拟到物理转化的时候查页表，发现映射的这个字符常量区是只读权限，但你的操作是想写，MMU在转化的时候发现你要对一个只具有读权限的地址进行写入了，所以就发生报错了，操作系统就知道CPU内部有内部错误了，就会把当前错误转化成信号，根据寄存器找到当前进程，修改比特位，给他发信号。再次调度进程，可能会遇到从用户到内核的切换，查信号，进程崩溃。

标记位的记录位置：
页表需要找页框，页表里存的是页框的地址，需要多少个比特位可以把页框全部保存起来？
每个页框4KB，就是(2^2)* (2^10)，页表项是32位，就是 2^32，相除之后就会是 2^20，也就是说只需要20个比特位就能找到任意一个页框了。那不是还剩12个比特位吗？
剩的这个12个比特位就是用来存放这个标记位

源代码也可以验证。
任何一个页框被加载进来的时候，标志位什么时间被设置的？加载的时候。所以加载的时候，要把代码段，数据段划分好，所以程序编译的时候，就划分了各种段，标志位就在这个时候设置了。

回到缺页中断这个主题：
当我们把虚拟地址转换成物理地址过程中，MMU读取地址，查操作是in，要写入，可是地址是只读存储区的地址，MMU报错，操作系统会把错误转换成信号。那么操作系统怎么知道你转化到物理地址的过程失败了呢？

MMU+TLB都在CPU里，MMU把虚拟地址转换成物理地址失败了相当于CPU出错了，也就是变成了软中断，发送中断信号，查找中断向量表。

同样的，假如一串代码有10w行，我们不需要全部加载进来，先加载进来1w，页表构建这1w行的映射关系就可以了，虚拟地址空间可以认为是10w行代码。此时执行完这1行，剩下的9万行没有加载进来，没有被页表构建关系，此时再查找页表就找不到剩下代码了，权限上被称为不命中了，此时MMU虚拟到物理转换失败，CPU出错了，自动形成软中断，再去查中断向量表，处理就可能是加载动作，把外设上剩下的代码重新加载进来，重新构建映射关系，这个因为没有命中，要求操作系统通过软中断执行新加载逻辑的过程叫做缺页中断。

补充：
现在我们如何理解之前的new 和 malloc？

实际上他们并没有真正申请内存，只需要申请虚拟地址空间，要么就是对堆区做扩容，把数字加加，然后把页表的关系维护起来，只不过页表的几个标志位 ，比如是否命中，为否，表示没有分配物理地址，物理地址为全0。当我们真正要用到时候，才给我们进行 缺页中断，查找中断向量表，处理对应的分配物理地址空间的方法。

怎么理解写实拷贝：

写实拷贝，就是fork创建子进程，父子进程刚开始，代码数据共享，也就是页表共享。所以发生写实拷贝时，把数据区的权限改成只读。此时子进程尝试进行写入时，没有写权限，也会发生缺页中断。
再拓展点：他写实拷贝是按照4KB为单位拷贝的，因此假如你想访问某一个变量，但是全局变量有几十个被编译到一块了，物理内存没有区分他们，他4KB为单位一拷贝，下次访问这个页框时，别的变量就不用拷贝了，以空间换时间。

申请内存，究竟是在干什么？

申请虚拟地址空间 && 填充修改页表

（7）cache

TLB缓存的是虚拟与物理地址之间的映射，而这个cache缓存的是代码与数据块，也就是说一旦cpu找到了物理地址，他并不是先把物理地址扔到系统总线上访存，而是拿着地址先查cache，如果查到了，直接把cache当中的代码和数据放入到寄存器当中。如果miss了吗，没有cache到，他访问物理内存了，就会把内存中块级别的数据导入到cache里，比如只访问了10字节的数据，他会把附件4KB的数据全导入进来，所以就可以加快操作系统给cpu喂指令的速度。这4KB加载到cache里并没有使用，本质是一种缓存机制，缓冲的本质是预加载。

如果我们访问某一行数据，把附件4KB全加载进来，万一用不到呢？

其实是基于概率的，假如在访问第十行数据，那么有很大概率访问第十一，十二行数据。另外，有较大概率访问正在访问数据附件的代码数据称为局部性原理。

如果没有预加载机制，内存还有存在的必要吗？

没有。内存的本质是cpu和外设的缓存，如果不存在局部性原理，要么就是把数据提前全加载到内存，要么就局部性地加载一部分，没有太大意义。因为当你访问时，操作系统没有办法把数据给你做预加载了，也就是写实拷贝那4kb就没意义了。

我们可以指令查看一下cpu，证明一下cache的存在：

cat /proc/cpuinfo

5、线程的优点

1. 创建一个新线程的代价要比创建一个新进程小得多
2. 与进程之间的切换相比，线程之间的切换需要操作系统做的工作要少很多

• 最主要的区别是线程的切换虚拟内存空间依然是相同的，但是进程切换是不同的。 这两种上下文切换的处理都是通过操作系统内核来完成的。内核的这种切换过程伴随的最显著的性能损耗是将寄存器中的内容切换出。
• 另外一个隐藏的损耗是上下文的切换会扰乱处理器的缓存机制。 简单的说，一旦去切换上下文，处理器中所有已经缓存的内存地址一瞬间都作废了。还有一个显著的区别是当你改变虚拟内存空间的时候，处理的页表缓冲 TLB(快表)会被全部刷新，这将导致内存的访问在一段时间内相当的低效。但是在线程的切换中，不会出现这个问题，当然还有硬件cache。

3. 线程占用的资源要比进程少很
4. 能充分利用多处理器的可并行数量
5. 在等待慢速I/0操作结束的同时，程序可执行其他的计算任务
6. 计算密集型应用，为了能在多处理器系统上运行，将计算分解到多个线程中实现
7. I/0密集型应用，为了提高性能，将I/0操作重叠。线程可以同时等待不同的I/0操作。

6、线程的缺点

1. 性能损失
   一个很少被外部事件阻塞的计算密集型线程往往无法与其它线程共享同一个处理器。如果计算密集型线程的数量比可用的处理器多，那么可能会有较大的性能损失，这里的性能损失指的是增加了额外的同步和调度开销，而可用的资源不变。
2. 健壮性降低
   编写多线程需要更全面更深入的考虑，在一个多线程程序里，因时间分配上的细微偏差或者因共享了不该共享的变量而造成不良影响的可能性是很大的，换句话说线程之间是缺乏保护的。
3. 缺乏访问控制
   进程是访问控制的基本粒度，在一个线程中调用某些OS函数会对整个进程造成影响。
4. 编程难度提高
   编写与调试一个多线程程序比单线程程序困难得多

7、线程异常

• 单个线程如果出现除零，野指针问题导致线程崩溃，进程也会随着崩溃。线程是进程内的一个分支，线程干了异常操作，就是进程干的，cpu发现某个pcb出了错误，整个pcb组都会被发比如野指针信号，所有执行流一起退出
• 线程是进程的执行分支，线程出异常，就类似进程出异常，进而触发信号机制，终止进程，进程终止，该进程内的所有线程也就随即退出

8、线程用途

• 合理的使用多线程，能提高CPU密集型程序的执行效率
• 合理的使用多线程，能提高I0密集型程序的用户体验(如生活中我们一边写代码一边下载开发工具，就是多线程运行的一种表现)

二、进程 VS 线程

1、进程和线程

1. 进程是资源分配的基本单位。
2. 线程是调度的基本单位。
3. 线程共享进程数据，共享的进程数据包括代码区、字符常量区、全局初始化和未初始化数据、堆区、共享区、命令行参数和环境变量、内核区等等。但也独立拥有自己的一部分数据，这一部分数据是不共享的：

• 线程 ID（即 LWP）
• 对应的寄存器数据（CPU 调度是按 PCB 调度的，每个线程都有自己的上下文数据，所以必须保证每个线程的上下文数据是各自私有的，这也体现了线程是可以切换的）
  栈（每个线程都有自己的栈结构，这也体现了线程是独立运行的）
• errno
• 信号屏蔽字（多线程中 block 表是私有的）
• 调度优先级

2、进程的多个线程共享

进程的多个线程共享同一地址空间， 因此 Text Segment 、 Data Segment 都是共享的， 如果定义一个函数， 在各线程中都可以调用， 如果定义一个全局变量， 在各线程中都可以访问到， 除此之外 各线程还共享以下进程资源和环境：

• 文件描述符表（注意在多进程中不共享文件描述符表，在管道我们说过两个进程可以指向同一个文件，其中并是说它们共享文件描述符表，而是它们表中的内容是一样的，而多线程是可以共享文件描述符表的）
• 每种信号的处理方式（SIG_ IGN、SIG_ DFL 或者自定义的信号处理函数）（handler 表是线程共享的）
• 当前工作目录（cwd）
• 用户 ID 和组 ID

3、进程和线程的关系

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

在此之前我们接触到的都是具有一个线程执行流的进程，即单线程进程。

三、Linux线程控制

1、POSIX线程库

pthread线程库是应用层的原生线程库：

• 应用层指的是这个线程库并不是系统接口直接提供的，而是由第三方帮我们提供的。
• 原生指的是大部分Linux系统都会默认带上该线程库。
• 与线程有关的函数构成了一个完整的系列，绝大多数函数的名字都是以“pthread_”打头的。
• 要使用这些函数库，要通过引入头文件<pthreaad.h>。
• 链接这些线程函数库时，要使用编译器命令的“-lpthread”选项。

错误检查：

• 传统的一些函数是，成功返回0，失败返回-1，并且对全局变量errno赋值以指示错误。
• pthreads函数出错时不会设置全局变量errno（而大部分POSIX函数会这样做），而是将错误代码通过返回值返回。
• pthreads同样也提供了线程内的errno变量，以支持其他使用errno的代码。对于pthreads函数的错误，建议通过返回值来判定，因为读取返回值要比读取线程内的errno变量的开销更小。

其实 pthread 库也是通过内核提供的系统调用(例如clone)来创建线程的，而内核会为每个线程创建系统全局唯一的“ID”来唯一标识这个线程。

2、线程创建

创建的函数我们之前讲过了，现在我们统一在过一遍

创建线程的函数叫做pthread_create

pthread_create函数的函数原型如下：

int pthread_create(pthread_t *thread, const pthread_attr_t *attr, void *(*start_routine) (void *), void *arg);

参数说明：

• thread：获取创建成功的线程ID，该参数是一个输出型参数。
• attr：用于设置创建线程的属性，传入NULL表示使用默认属性。
• start_routine：该参数是一个函数地址，表示线程例程，即线程启动后要执行的函数。
• arg：传给线程例程的参数。

返回值说明：

• 线程创建成功返回0，失败返回错误码。

routine是个回调函数，void *arg传给了routine

补： c++支持多线程，本质是封装了pthread库！
我们可以用c++使用的接口，不用phread库验证，如果编译时候g++ -o $@ $^ -std=c++11 -lpthread 不加最后的-lpthread还是会报错。

3、获取线程ID

常见获取线程ID的方式有两种：

• 创建线程时通过输出型参数获得。
• 通过调用pthread_self函数获得。

1. 创建线程时通过输出型参数获得：

#include <iostream>
#include <string>
#include <cstdio>
#include <cstring>
#include <unistd.h>
#include <thread>

void *routine(void *args)
{
    std::string name = static_cast<const char *>(args);
    while (true)
    {
        std::cout << "我是新线程，我的名字是：" << name << std::endl;
        sleep(1);
    }
    return 0;
}

int main()
{
    pthread_t tid;
    pthread_create(&tid, nullptr, routine, (void *)"thread-1");
    //std::cout << "new thread id: " << tid << std::endl;
    printf("new thread id: 0x%lx\n", tid);

    while (true)
    {
        std::cout << "我是main线程..." << std::endl;
        sleep(1);
    }
}

2. 通过调用pthread_self函数获得：

pthread_self函数的函数原型如下：

pthread_t pthread_self(void);

调用pthread_self函数即可获得当前线程的ID，类似于调用getpid函数获取当前进程的ID。

例如，下面代码中在每一个新线程被创建后，主线程都将通过输出型参数获取到的线程ID进行打印，此后主线程和新线程又通过调用pthread_self函数获取到自身的线程ID进行打印。

#include <iostream>
#include <string>
#include <cstdio>
#include <cstring>
#include <unistd.h>
#include <thread>

std::string toHex(pthread_t tid)
{
    char buffer[64];
    snprintf(buffer, sizeof(buffer), "0x%lx", tid);
    return buffer;
}

void *routine(void *args)
{
    std::string name = static_cast<const char *>(args);
    while (true)
    {
        std::cout << "我是新线程，我的名字是：" << name <<", my tid is : "<< toHex(pthread_self())<< std::endl;
        sleep(1);
    }
    return 0;
}

int main()
{
    pthread_t tid;
    pthread_create(&tid, nullptr, routine, (void *)"thread-1");
    //std::cout << "new thread id: " << tid << std::endl;
    printf("new thread id: 0x%lx\n", tid);

    while (true)
    {
        std::cout << "我是main线程..." << std::endl;
        sleep(1);
    }
}

运行代码，可以看到这两种方式获取到的线程的ID是一样的 。

当然我们也可以创建多个线程并打印

#include <iostream>
#include <string>
#include <cstdio>
#include <cstring>
#include <unistd.h>
#include <thread>

std::string toHex(pthread_t tid)
{
    char buffer[64];
    snprintf(buffer, sizeof(buffer), "0x%lx", tid);
    return buffer;
}

void *routine(void *args)
{
    std::string name = static_cast<const char *>(args);
    while (true)
    {
        std::cout << "我是新线程，我的名字是：" << name <<", my tid is : "<< toHex(pthread_self())<< std::endl;
        sleep(1);
    }
    return 0;
}

int main()
{
    pthread_t tid1;
    pthread_create(&tid1, nullptr, routine, (void *)"thread-1");

    pthread_t tid2;
    pthread_create(&tid2, nullptr, routine, (void *)"thread-2");

    pthread_t tid3;
    pthread_create(&tid3, nullptr, routine, (void *)"thread-3");

    pthread_t tid4;
    pthread_create(&tid4, nullptr, routine, (void *)"thread-4");
    //std::cout << "new thread id: " << tid << std::endl;
    printf("new thread id: 0x%lx\n", tid1);
    printf("new thread id: 0x%lx\n", tid2);
    printf("new thread id: 0x%lx\n", tid3);
    printf("new thread id: 0x%lx\n", tid4);

    while (true)
    {
        std::cout << "我是main线程..." << std::endl;
        sleep(1);
    }
}

但是我们会发现，打印出来的信息是错乱的：这是因为在不加班保护情况下，显示器文件就是共享资源，他被重入了。

4、线程等待

首先需要明确的是，一个线程被创建出来，这个线程就如同进程一般，也是需要被等待的。如果主线程不对新线程进行等待，那么这个新线程的资源也是不会被回收的。所以线程需要被等待，如果不等待会产生类似于“僵尸进程”的问题，也就是内存泄漏。

等待线程的函数叫做pthread_join

pthread_join函数的函数原型如下：

int pthread_join(pthread_t thread, void **retval);

参数说明：

• thread：被等待线程的ID。
• retval：线程退出时的退出码信息。

返回值说明：

• 线程等待成功返回0，失败返回错误码。

调用该函数的线程将挂起等待，直到ID为thread的线程终止，thread线程以不同的方法终止，通过pthread_join得到的终止状态是不同的。
总结如下：

• 如果thread线程通过return返回，retval所指向的单元里存放的是thread线程函数的返回值。
• 如果thread线程被别的线程调用pthread_cancel异常终止掉，retval所指向的单元里存放的是常数PTHREAD_CANCELED。
  

用grep命令进行查找，可以发现PTHREAD_CANCELED实际上就是头文件<pthread.h>里面的一个宏定义，它的值本质就是-1。
syc@VM-4-17-ubuntu:~$ grep -ER "PTHREAD_CANCELED" /usr/include/

• 如果thread线程是自己调用pthread_exit终止的，retval所指向的单元存放的是传给pthread_exit的参数。
• 如果对thread线程的终止状态不感兴趣，可以传NULL给retval参数。

例如，在下面的代码中我们先不关心线程的退出信息，直接将pthread_join函数的第二次参数设置为NULL，等待线程后打印该线程的编号以及线程ID。

#include <stdio.h>
#include <stdlib.h>
#include <pthread.h>
#include <unistd.h>
#include <sys/types.h>

void* Routine(void* arg)
{
	char* msg = (char*)arg;
	int count = 0;
	while (count < 5){
		printf("I am %s...pid: %d, ppid: %d, tid: %lu\n", msg, getpid(), getppid(), pthread_self());
		sleep(1);
		count++;
	}
	return NULL;
}
int main()
{
	pthread_t tid[5];
	for (int i = 0; i < 5; i++){
		char* buffer = (char*)malloc(64);
		sprintf(buffer, "thread %d", i);
		pthread_create(&tid[i], NULL, Routine, buffer);
		printf("%s tid is %lu\n", buffer, tid[i]);
	}
	printf("I am main thread...pid: %d, ppid: %d, tid: %lu\n", getpid(), getppid(), pthread_self());
	for (int i = 0; i < 5; i++){
		pthread_join(tid[i], NULL);
		printf("thread %d[%lu]...quit\n", i, tid[i]);
	}
	return 0;
}

下面我们再来看看如何获取线程退出时的退出码，为了便于查看，我们这里将线程退出时的退出码设置为某个特殊的值，并在成功等待线程后将该线程的退出码进行输出。

#include <stdio.h>
#include <stdlib.h>
#include <pthread.h>
#include <unistd.h>
#include <sys/types.h>

void* Routine(void* arg)
{
	char* msg = (char*)arg;
	int count = 0;
	while (count < 5){
		printf("I am %s...pid: %d, ppid: %d, tid: %lu\n", msg, getpid(), getppid(), pthread_self());
		sleep(1);
		count++;
	}
	return (void*)2022;
}
int main()
{
	pthread_t tid[5];
	for (int i = 0; i < 5; i++){
		char* buffer = (char*)malloc(64);
		sprintf(buffer, "thread %d", i);
		pthread_create(&tid[i], NULL, Routine, buffer);
		printf("%s tid is %lu\n", buffer, tid[i]);
	}
	printf("I am main thread...pid: %d, ppid: %d, tid: %lu\n", getpid(), getppid(), pthread_self());
	for (int i = 0; i < 5; i++){
		void* ret = NULL;
		pthread_join(tid[i], &ret);
		printf("thread %d[%lu]...quit, exitcode: %lld\n", i, tid[i], (long long int)ret);
	}
	return 0;
}

运行代码，此时我们就拿到了每个线程退出时的退出码信息。

注意： pthread_join函数默认是以阻塞的方式进行线程等待的。

为什么线程退出时只能拿到线程的退出码？

如果我们等待的是一个进程，那么当这个进程退出时，我们可以通过wait函数或是waitpid函数的输出型参数status，获取到退出进程的退出码、退出信号以及core dump标志。

那为什么等待线程时我们只能拿到退出线程的退出码？难道线程不会出现异常吗？

线程在运行过程中当然也会出现异常，线程和进程一样，线程退出的情况也有三种：

• 代码运行完毕，结果正确。
• 代码运行完毕，结果不正确。
• 代码异常终止。

因此我们也需要考虑线程异常终止的情况，但是pthread_join函数无法获取到线程异常退出时的信息。因为线程是进程内的一个执行分支，如果进程中的某个线程崩溃了，那么整个进程也会因此而崩溃，此时我们根本没办法执行pthread_join函数，因为整个进程已经退出了。

例如，我们在线程的执行例程当中制造一个除零错误，当某一个线程执行到此处时就会崩溃，进而导致整个进程崩溃。

#include <stdio.h>
#include <stdlib.h>
#include <pthread.h>
#include <unistd.h>
#include <sys/types.h>

void* Routine(void* arg)
{
	char* msg = (char*)arg;
	int count = 0;
	while (count < 5){
		printf("I am %s...pid: %d, ppid: %d, tid: %lu\n", msg, getpid(), getppid(), pthread_self());
		sleep(1);
		count++;
		int a = 1 / 0; //error
	}
	return (void*)2022;
}
int main()
{
	pthread_t tid[5];
	for (int i = 0; i < 5; i++){
		char* buffer = (char*)malloc(64);
		sprintf(buffer, "thread %d", i);
		pthread_create(&tid[i], NULL, Routine, buffer);
		printf("%s tid is %lu\n", buffer, tid[i]);
	}
	printf("I am main thread...pid: %d, ppid: %d, tid: %lu\n", getpid(), getppid(), pthread_self());
	for (int i = 0; i < 5; i++){
		void* ret = NULL;
		pthread_join(tid[i], &ret);
		printf("thread %d[%lu]...quit, exitcode: %d\n", i, tid[i], (int)ret);
	}
	return 0;
}

运行代码，可以看到一旦某个线程崩溃了，整个进程也就跟着挂掉了，此时主线程连等待新线程的机会都没有，这也说明了多线程的健壮性不太强，一个进程中只要有一个线程挂掉了，那么整个进程就挂掉了。并且此时我们也不知道是由于哪一个线程崩溃导致的，我们只知道是这个进程崩溃了。

所以pthread_join函数只能获取到线程正常退出时的退出码，用于判断线程的运行结果是否正确。

5、线程终止

如果需要只终止某个线程而不是终止整个进程，可以有三种方法：

• 从线程函数return。
• 线程可以自己调用pthread_exit函数终止自己。
• 一个线程可以调用pthread_cancel函数终止同一进程中的另一个线程。

（1）return退出

在线程中使用return代表当前线程退出，但是在main函数中使用return代表整个进程退出，也就是说只要主线程退出了那么整个进程就退出了，此时该进程曾经申请的资源就会被释放，而其他线程会因为没有了资源，自然而然的也退出了。

例如，在下面代码中，主线程创建五个新线程后立刻进行return，那么整个进程也就退出了。

#include <stdio.h>
#include <stdlib.h>
#include <pthread.h>
#include <unistd.h>
#include <sys/types.h>

void* Routine(void* arg)
{
	char* msg = (char*)arg;
	while (1){
		printf("I am %s...pid: %d, ppid: %d, tid: %lu\n", msg, getpid(), getppid(), pthread_self());
		sleep(1);
	}
	return (void*)0;
}
int main()
{
	pthread_t tid[5];
	for (int i = 0; i < 5; i++){
		char* buffer = (char*)malloc(64);
		sprintf(buffer, "thread %d", i);
		pthread_create(&tid[i], NULL, Routine, buffer);
		printf("%s tid is %lu\n", buffer, tid[i]);
	}
	printf("I am main thread...pid: %d, ppid: %d, tid: %lu\n", getpid(), getppid(), pthread_self());

	return 0;
}

运行代码，并不能看到新线程执行的打印操作，因为主线程的退出（最后的return 0)导致整个进程退出了。

（2）pthread_exit函数

pthread_exit函数的功能就是终止线程，pthread_exit函数的函数原型如下：

void pthread_exit(void *retval);

参数说明：

• retval：线程退出时的退出码信息。

说明一下：

• 该函数无返回值，跟进程一样，线程结束的时候无法返回它的调用者（自身）。
• pthread_exit或者return返回的指针所指向的内存单元必须是全局的或者是用malloc分配的，不能在线程函数的栈上分配，因为当其他线程得到这个返回指针时，线程函数已经退出了。
  例如，在下面代码中，我们使用pthread_exit函数终止线程：

#include <iostream>
#include <string>
#include <cstdio>
#include <cstring>
#include <unistd.h>
#include <thread>

void *start(void *args)
{
    std::string name = static_cast<const char *>(args);
    while (true)
    {
        sleep(1);
        break;
    }

    pthread_exit((void*)10);
}

int main()
{
    pthread_t tid;
    pthread_create(&tid, nullptr, start, (void *)"thread-1");

    void *ret = nullptr;
    pthread_join(tid, &ret);
    std::cout << "new thread exit code: " << (long long int)ret << std::endl;

    return 0; // 9. 主线程return，表示进程结束！
}

运行代码可以看到，当线程退出时其退出码就是我们设置的10。

（3）pthread_cancel函数

线程是可以被取消的，我们可以使用pthread_cancel函数取消某一个线程，pthread_cancel函数的函数原型如下：

int pthread_cancel(pthread_t thread);

参数说明：

• thread：被取消线程的ID。

返回值说明：

• 线程取消成功返回0，失败返回错误码。

线程是可以取消自己的，取消成功的线程的退出码一般是-1。例如在下面的代码中，我们让线程执行一次打印操作后将自己取消。

#include <iostream>
#include <string>
#include <cstdio>
#include <cstring>
#include <unistd.h>
#include <thread>

void *start(void *args)
{
    std::string name = static_cast<const char *>(args);
    while (true)
    {
        std::cout << "I am a new thread" << std::endl;
        sleep(1);
        break;
    }
    return ((void*)10);
}

int main()
{
    pthread_t tid;
    pthread_create(&tid, nullptr, start, (void *)"thread-1");
 
    sleep(5);

    pthread_cancel(tid);
    std::cout << "取消线程: " << tid << std::endl;

    sleep(5);

    void *ret = nullptr;
    pthread_join(tid, &ret); 
    std::cout << "new thread exit code: " << (long long int)ret << std::endl;


    return 0; // 9. 主线程return，表示进程结束！
}

6、 分离线程

• 默认情况下，新创建的线程是joinable的，线程退出后，需要对其进行pthread_join操作，否则无法释放资源，从而造成内存泄漏。
• 但如果我们不关心线程的返回值，join也是一种负担，此时我们可以将该线程进行分离，后续当线程退出时就会自动释放线程资源。
• 一个线程如果被分离了，这个线程依旧要使用该进程的资源，依旧在该进程内运行，甚至这个线程崩溃了一定会影响其他线程，只不过这个线程退出时不再需要主线程去join了，当这个线程退出时系统会自动回收该线程所对应的资源。
• 可以是线程组内其他线程对目标线程进行分离，也可以是线程自己分离。
• joinable和分离是冲突的，一个线程不能既是joinable又是分离的。

（1）pthread_detach

分离线程的函数叫做pthread_detach
用于创建线程，它是一个回调函数。如果线程创建成功，则会执行 start_routine，编译和链接时需要引入 pthread。

pthread_detach函数的函数原型如下：

int pthread_detach(pthread_t thread);

参数说明：

• thread：被分离线程的ID。

返回值说明：

• 线程分离成功返回0，失败返回错误码。

现在我们写一个代码，让目标线程与主线程分离，此时pthread_join就会失败，他不会阻塞在这里，返回值为错误码，不为0。

#include <iostream>
#include <string>
#include <cstdio>
#include <cstring>
#include <unistd.h>
#include <thread>

void *start(void *args)
{
    std::string name = static_cast<const char *>(args);
    while (true)
    {
        std::cout << "I am a new thread" << std::endl;
        sleep(1);
        break;
    }
    return ((void*)10);
}

int main()
{
    pthread_t tid;
    pthread_create(&tid, nullptr, start, (void *)"thread-1");
    pthread_detach(tid);

    sleep(5);
    void *ret = nullptr;
    int n = pthread_join(tid, &ret); 
    std::cout << "new thread exit code: " << (long long int)ret <<" ,n: "<< n << std::endl;

    return 0; // 9. 主线程return，表示进程结束！
}

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

• pthread_create函数会产生一个线程ID，存放在第一个参数指向的地址中，该线程ID和内核中的LWP不是一回事。
• 内核中的LWP属于进程调度的范畴，因为线程是轻量级进程，是操作系统调度器的最小单位，所以需要一个数值来唯一表示该线程。
• pthread_create函数第一个参数指向一个虚拟内存单元，该内存单元的地址即为新创建线程的线程ID，这个ID属于NPTL线程库的范畴，线程库的后续操作就是根据该线程ID来操作线程的。
• 线程库NPTL提供的pthread_self函数，获取的线程ID和pthread_create函数第一个参数获取的线程ID是一样的。

pthread_t到底是什么类型呢？
首先，Linux不提供真正的线程，只提供LWP，也就意味着操作系统只需要对内核执行流LWP进行管理，而供用户使用的线程接口等其他数据，应该由线程库自己来管理，因此管理线程时的“先描述，再组织”就应该在线程库里进行。

通过ldd命令可以看到，我们采用的线程库实际上是一个动态库。

进程运行时动态库被加载到内存，然后通过页表映射到进程地址空间中的共享区，此时该进程内的所有线程都是能看到这个动态库的。

我们说每个线程都有自己私有的栈，其中主线程采用的栈是进程地址空间中原生的栈，而其余线程采用的栈就是在共享区中开辟的。除此之外，每个线程都有自己的struct pthread，当中包含了对应线程的各种属性；每个线程还有自己的线程局部存储，当中包含了对应线程被切换时的上下文数据。
我们可以添加__thread在前面，让每个线程中都拷贝一份share_value。

每一个新线程在共享区都有这样一块区域对其进行描述，因此我们要找到一个用户级线程只需要找到该线程内存块的起始地址，然后就可以获取到该线程的各种信息。

上面我们所用的各种线程函数，本质都是在库内部对线程属性进行的各种操作，最后将要执行的代码交给对应的内核级LWP去执行就行了，也就是说线程数据的管理本质是在共享区的。

pthread_t到底是什么类型取决于实现，但是对于Linux目前实现的NPTL线程库来说，线程ID本质就是进程地址空间共享区上的一个虚拟地址，同一个进程中所有的虚拟地址都是不同的，因此可以用它来唯一区分每一个线程。

附录

线程栈：
虽然 Linux 将线程和进程不加区分的统一到了 task_struct ，但是对待其地址空间的 stack 还是有些区别的。

• 对于 Linux 进程或者说主线程，简单理解就是main函数的栈空间，在fork的时候，实际上就是复制了父亲的 stack 空间地址，然后写时拷贝(cow)以及动态增长。如果扩充超出该上限则栈溢出会报段错误(发送段错误信号给该进程)。进程栈是唯一可以访问未映射页而不一定会发生段错误–超出扩充上限才报。
• 然而对于主线程生成的子线程而言，其stack 将不再是向下生长的，而是事先固定下来的。线程栈一般是调用glibc/uclibc等的 pthread 库接口 pthread_create 创建的线程，在文件映射区(或称之为共享区)。其中使用 mmap 系统调用，这个可以从glibc的nptl/allocatestack.c中的allocate_stack 函数中看到：

mem = mmap(NULL,size,prot,
	MAP_PRIVATE|MAP_ANONYMOUS |MAP_STACK, -1,0);

此调用中的 size 参数的获取很是复杂，你可以手工传入stack的大小，也可以使用默认的，一般而言就是默认的 8M 。这些都不重要，重要的这种stack不能动态增长，一旦用尽就没了，这是和生成进程的fork不同的地方。 在glibc中通过mmap得到了stack之后，底层将调用 sys_clone 系统调用：

因此，对于子线程的 stack，它其实是在进程的地址空间中map出来的一块内存区域，原则上是线程私有的，但是同一个进程的所有线程生成的时候，是会浅拷贝生成者的 task_struct的很多字段，如果愿意，其它线程也还是可以访问到的，于是一定要注意。