linux 线程 机制 探索

最近在整理线程的时候，知道linux中线程是轻量级的进程，那么进程怎么就能当线程用呢？进程之间的共享是怎么做到的呢？

轻量级线程是什么？轻量级进程肯定也是进程，那么pid（processid）和tid（threadid）之间的关系呢？

我将在下面对这些问题说说我的理解。

一个进程至少需要一个线程作为它的指令执行体，进程管理着资源（比如cpu、内存、文件等等），而将线程分配到某个cpu上执行。一个进程当然可以拥有多个线程。

线程又可以分为核心级线程和用户级线程两种线程模型（如果有疑惑，请参考前一篇博客）

而对应到linux中，我们常听说的linux没有线程，准确的说是linux中没有纯粹的线程，它是通过轻量级的进程实现了线程的功能。

所以说呢？在linux中进程是一个执行单元, 维护着执行相关的动态资源（一般系统中线程管理的资源，如线程运行栈等）. 同时, 它又引用着程序所需的静态资源（进程的资源）。至于为什么linux还是不直接引入线程这个东西，我是不太明白，可能linux的开发大牛们认为这个东西已经够好了吧。

虽然说linux没有引入线程，但是他们使用了轻量级的进程实现了POSIX中大部分线程所实现的功能。

那么到底轻量级进程是什么呢？其实说到底就是多个进程共享了进程的资源，不管那个进程修改了这写信息，那么其它进程也会受到影响。

linux的线程是怎么创建的？

linux的线程是又轻量级进程实现的，是由用户态的phtread库进行实现的

在使用pthread库后，在用户看来，一个task_struct对应一个线程。同一组线程和他们公用的资源就组成了进程。但是不是说一组线程就只是引用共享资源那么简单。

POSIX对此做出了规定：

查看进程列表的时候, 相关的一组task_struct应当被展现为列表中的一个节点;
发送给这个"进程"的信号(对应kill系统调用), 将被对应的这一组task_struct所共享, 并且被其中的任意一个"线程"处理;
发送给某个"线程"的信号(对应pthread_kill), 将只被对应的一个task_struct接收, 并且由它自己来处理;
当"进程"被停止或继续时(对应SIGSTOP/SIGCONT信号), 对应的这一组task_struct状态将改变;
当"进程"收到一个致命信号(比如由于段错误收到SIGSEGV信号), 对应的这一组task_struct将全部退出;
等等(以上可能不够全);

下面将说说，linux对于线程“进化史”

LinuxThreads

在linux 2.6以前, pthread线程库对应的实现是一个名叫linuxthreads的lib.

linuxthreads利用前面提到的轻量级进程来实现线程, 但是对于POSIX提出的那些要求, linuxthreads除了第5点以外, 都没有实现(实际上是无能为力):

1, 如果运行了A程序, A程序创建了10个线程, 那么在shell下执行ps命令时将看到11个A进程, 而不是1个(注意, 也不是10个, 下面会解释);

2, 不管是kill还是pthread_kill, 信号只能被一个对应的线程所接收;

3, SIGSTOP/SIGCONT信号只对一个线程起作用;

还好linuxthreads实现了第5点, 我认为这一点是最重要的. 如果某个线程"挂"了, 整个进程还在若无其事地运行着, 可能会出现很多的不一致状态. 进程将不是一个整体, 而线程也不能称为线程.

或许这也是为什么linuxthreads虽然与POSIX的要求差距甚远, 却能够存在, 并且还被使用了好几年的原因吧~

但是, linuxthreads为了实现这个"第5点", 还是付出了很多代价, 并且创造了linuxthreads本身的一大性能瓶颈.

接下来要说说, 为什么A程序创建了10个线程, 但是ps时却会出现11个A进程了. 因为linuxthreads自动创建了一个管理线程. 上面提到的"第5点"就是靠管理线程来实现的.

当程序开始运行时, 并没有管理线程存在(因为尽管程序已经链接了pthread库, 但是未必会使用多线程).

程序第一次调用pthread_create时, linuxthreads发现管理线程不存在, 于是创建这个管理线程. 这个管理线程是进程中的第一个线程(主线程)的儿子.

然后在pthread_create中, 会通过pipe向管理线程发送一个命令, 告诉它创建线程. 即是说, 除主线程外, 所有的线程都是由管理线程来创建的, 管理线程是它们的父亲.

于是, 当任何一个子线程退出时, 管理线程将收到SIGUSER1信号(这是在通过clone创建子线程时指定的). 管理线程在对应的sig_handler中会判断子线程是否正常退出, 如果不是, 则杀死所有线程, 然后自杀.

那么, 主线程怎么办呢? 主线程是管理线程的父亲, 其退出时并不会给管理线程发信号. 于是, 在管理线程的主循环中通过getppid检查父进程的ID号, 如果ID号是1, 说明父亲已经退出, 并把自己托管给了init进程(1号进程). 这时候, 管理线程也会杀掉所有子线程, 然后自杀. 那么, 如果主线程是调用pthread_exit主动退出的呢? 按照posix的标准，这种情况下其他子线程是应该继续运行的. 于是, 在linuxthreads中, 主线程调用pthread_exit以后并不会真正退出, 而是会在pthread_exit函数中阻塞等待所有子线程都退出了,
pthread_exit才会让主线程退出. (在这个等等过程中, 主线程一直处于睡眠状态.)

可见, 线程的创建与销毁都是通过管理线程来完成的, 于是管理线程就成了linuxthreads的一个性能瓶颈.

创建与销毁需要一次进程间通信, 一次上下文切换之后才能被管理线程执行, 并且多个请求会被管理线程串行地执行.

NPTL

了linux 2.6, glibc中有了一种新的pthread线程库--NPTL(Native POSIX Threading Library).

NPTL实现了前面提到的POSIX的全部5点要求. 但是, 实际上, 与其说是NPTL实现了, 不如说是linux内核实现了.

在linux 2.6中, 内核有了线程组的概念, task_struct结构中增加了一个tgid(thread group id)字段.

如果这个task是一个"主线程", 则它的tgid等于pid, 否则tgid等于进程的pid(即主线程的pid).

在clone系统调用中, 传递CLONE_THREAD参数就可以把新进程的tgid设置为父进程的tgid(否则新进程的tgid会设为其自身的pid).

类似的XXid在task_struct中还有两个：task->signal->pgid保存进程组的打头进程的pid、task->signal->session保存会话打头进程的pid。通过这两个id来关联进程组和会话。

有了tgid, 内核或相关的shell程序就知道某个tast_struct是代表一个进程还是代表一个线程, 也就知道在什么时候该展现它们, 什么时候不该展现(比如在ps的时候, 线程就不要展现了).

而getpid(获取进程ID)系统调用返回的也是tast_struct中的tgid, 而tast_struct中的pid则由gettid系统调用来返回.

在执行ps命令的时候不展现子线程，也是有一些问题的。比如程序a.out运行时，创建了一个线程。假设主线程的pid是10001、子线程是10002（它们的tgid都是10001）。这时如果你kill 10002，是可以把10001和10002这两个线程一起杀死的，尽管执行ps命令的时候根本看不到10002这个进程。如果你不知道linux线程背后的故事，肯定会觉得遇到灵异事件了。

为了应付"发送给进程的信号"和"发送给线程的信号", task_struct里面维护了两套signal_pending, 一套是线程组共享的, 一套是线程独有的.

通过kill发送的信号被放在线程组共享的signal_pending中, 可以由任意一个线程来处理; 通过pthread_kill发送的信号(pthread_kill是pthread库的接口, 对应的系统调用中tkill)被放在线程独有的signal_pending中, 只能由本线程来处理.

当线程停止/继续, 或者是收到一个致命信号时, 内核会将处理动作施加到整个线程组中.