Linux下thread编程（1）

http://blog.sina.com.cn/s/blog_602f87700100dqmk.html

Sam前些天在提供一个库给别的公司时，因为不喜欢使用pthread_jion等函数，被人骂为垃圾程序。呵呵，之前因为在写多thread程序时，习惯让每个thread都为detach属性，这样他们就可以自我管理。而不需要再由别人回收资源。呵呵，不说这么多了，把POSIXthread方面的东西记下来吧。

 

Linux下thread历史（Oldpthread与NPTL）：

Linux创建之初，并不能真正支持thread. LinuxThreads项目使用clone()这个系统调用实现对thread的模拟。在_clone本来的意图是创建一个可定义各种配置的对当前进程的拷贝。LinuxThreads项目则利用了这一点，配置了一个与调用进程拥有相同地址空间的拷贝，把它作为一个thread.所以，常常有人说，linux下面没有进程线程之分，其实就是这个意思。但这个方法也有问题，尤其是在信号处理、调度和进程间同步原语方面都存在问题。另外，这个线程模型也不符合POSIX 的要求。

 

如果要改进LinuxThread.很明显，需要kernel层的支持。IBM和RedHat分别进行了研究，随着IBM的放弃，RedHat的Native POSIXThread Library（NPTL）就成唯一的解决方案了。这就是NPTL。

 

 

 

 

LinuxThreads最初的设计相信相关进程之间的上下文切换速度很快，因此每个内核线程足以处理很多相关的用户级线程。这就导致了一对一线程模型的革命。

 

LinuxThreads 设计细节的一些基本理念：

 

LinuxThreads 非常出名的一个特性就是管理线程（managerthread）。管理线程可以满足以下要求：

• 系统必须能够响应终止信号并杀死整个进程。
• 以堆栈形式使用的内存回收必须在线程完成之后进行。因此，线程无法自行完成这个过程。
• 终止线程必须进行等待，这样它们才不会进入僵尸状态。
• 线程本地数据的回收需要对所有线程进行遍历；这必须由管理线程来进行。
• 如果主线程需要调用pthread_exit()，那么这个线程就无法结束。主线程要进入睡眠状态，而管理线程的工作就是在所有线程都被杀死之后来唤醒这个主线程。

• 为了维护线程本地数据和内存，LinuxThreads 使用了进程地址空间的高位内存（就在堆栈地址之下）。
  
  
• 原语的同步是使用信号 来实现的。例如，线程会一直阻塞，直到被信号唤醒为止。
  
  
• 在克隆系统的最初设计之下，LinuxThreads 将每个线程都是作为一个具有惟一进程 ID 的进程实现的。
  
  
• 终止信号可以杀死所有的线程。LinuxThreads接收到终止信号之后，管理线程就会使用相同的信号杀死所有其他线程（进程）。
  
  
• 根据 LinuxThreads的设计，如果一个异步信号被发送了，那么管理线程就会将这个信号发送给一个线程。如果这个线程现在阻塞了这个信号，那么这个信号也就会被挂起。这是因为管理线程无法将这个信号发送给进程；相反，每个线程都是作为一个进程在执行。
  
• 线程之间的调度是由内核调度器来处理的。

 

LinuxThreads及其局限性

LinuxThreads的设计通常都可以很好地工作；但是在压力很大的应用程序中，它的性能、可伸缩性和可用性都会存在问题。下面让我们来看一下LinuxThreads 设计的一些局限性：

• 它使用管理线程来创建线程，并对每个进程所拥有的所有线程进行协调。这增加了创建和销毁线程所需要的开销。
  
  
• 由于它是围绕一个管理线程来设计的，因此会导致很多的上下文切换的开销，这可能会妨碍系统的可伸缩性和性能。
  
  
• 由于管理线程只能在一个 CPU 上运行，因此所执行的同步操作在 SMP 或 NUMA系统上可能会产生可伸缩性的问题。
  
  
• 由于线程的管理方式，以及每个线程都使用了一个不同的进程 ID，因此 LinuxThreads 与其他与 POSIX相关的线程库并不兼容。
  
  
• 信号用来实现同步原语，这会影响操作的响应时间。另外，将信号发送到主进程的概念也并不存在。因此，这并不遵守 POSIX中处理信号的方法。
  
  
• LinuxThreads中对信号的处理是按照每线程的原则建立的，而不是按照每进程的原则建立的，这是因为每个线程都有一个独立的进程ID。由于信号被发送给了一个专用的线程，因此信号是串行化的 —— 也就是说，信号是透过这个线程再传递给其他线程的。这与POSIX 标准对线程进行并行处理的要求形成了鲜明的对比。例如，在 LinuxThreads 中，通过kill()所发送的信号被传递到一些单独的线程，而不是集中整体进行处理。这意味着如果有线程阻塞了这个信号，那么 LinuxThreads就只能对这个线程进行排队，并在线程开放这个信号时在执行处理，而不是像其他没有阻塞信号的线程中一样立即处理这个信号。
  
  
• 由于 LinuxThreads 中的每个线程都是一个进程，因此用户和组 ID的信息可能对单个进程中的所有线程来说都不是通用的。例如，一个多线程的setuid()/setgid()进程对于不同的线程来说可能都是不同的。
  
  
• 有一些情况下，所创建的多线程核心转储中并没有包含所有的线程信息。同样，这种行为也是每个线程都是一个进程这个事实所导致的结果。如果任何线程发生了问题，我们在系统的核心文件中只能看到这个线程的信息。不过，这种行为主要适用于早期版本的LinuxThreads 实现。
  
  
• 由于每个线程都是一个单独的进程，因此 /proc 目录中会充满众多的进程项，而这实际上应该是线程。
  
  
• 由于每个线程都是一个进程，因此对每个应用程序只能创建有限数目的线程。例如，在 IA32 系统上，可用进程总数 ——也就是可以创建的线程总数 —— 是 4,090。
  
  
• 由于计算线程本地数据的方法是基于堆栈地址的位置的，因此对于这些数据的访问速度都很慢。另外一个缺点是用户无法可信地指定堆栈的大小，因为用户可能会意外地将堆栈地址映射到本来要为其他目的所使用的区域上了。按需增长（growon demand） 的概念（也称为浮动堆栈 的概念）是在 2.4.10 版本的 Linux内核中实现的。在此之前，LinuxThreads 使用的是固定堆栈。

 

 

 

 

关于 NPTL

NPTL，或称为 Native POSIX Thread Library，是 Linux 线程的一个新实现，它克服了LinuxThreads 的缺点，同时也符合 POSIX 的需求。与 LinuxThreads相比，它在性能和稳定性方面都提供了重大的改进。与 LinuxThreads 一样，NPTL 也实现了一对一的模型。

Ulrich Drepper 和 Ingo Molnar 是 Red Hat 参与 NPTL设计的两名员工。他们的总体设计目标如下：

• 这个新线程库应该兼容 POSIX 标准。
  
  
• 这个线程实现应该在具有很多处理器的系统上也能很好地工作。
  
  
• 为一小段任务创建新线程应该具有很低的启动成本。
  
  
• NPTL 线程库应该与 LinuxThreads 是二进制兼容的。注意，为此我们可以使用LD_ASSUME_KERNEL，这会在本文稍后进行讨论。
  
  
• 这个新线程库应该可以利用 NUMA 支持的优点。

NPTL 的优点

与 LinuxThreads 相比，NPTL 具有很多优点：

• NPTL没有使用管理线程。管理线程的一些需求，例如向作为进程一部分的所有线程发送终止信号，是并不需要的；因为内核本身就可以实现这些功能。内核还会处理每个线程堆栈所使用的内存的回收工作。它甚至还通过在清除父线程之前进行等待，从而实现对所有线程结束的管理，这样可以避免僵尸进程的问题。
  
  
• 由于 NPTL 没有使用管理线程，因此其线程模型在 NUMA 和 SMP 系统上具有更好的可伸缩性和同步机制。
  
  
• 使用 NPTL 线程库与新内核实现，就可以避免使用信号来对线程进行同步了。为了这个目的，NPTL 引入了一种名为futex 的新机制。futex 在共享内存区域上进行工作，因此可以在进程之间进行共享，这样就可以提供进程间 POSIX同步机制。我们也可以在进程之间共享一个 futex。这种行为使得进程间同步成为可能。实际上，NPTL 包含了一个PTHREAD_PROCESS_SHARED宏，使得开发人员可以让用户级进程在不同进程的线程之间共享互斥锁。
  
  
• 由于 NPTL 是 POSIX 兼容的，因此它对信号的处理是按照每进程的原则进行的；getpid()会为所有的线程返回相同的进程 ID。例如，如果发送了SIGSTOP 信号，那么整个进程都会停止；使用LinuxThreads，只有接收到这个信号的线程才会停止。这样可以在基于 NPTL 的应用程序上更好地利用调试器，例如GDB。
  
  
• 由于在 NPTL 中所有线程都具有一个父进程，因此对父进程汇报的资源使用情况（例如 CPU和内存百分比）都是对整个进程进行统计的，而不是对一个线程进行统计的。
  
  
• NPTL 线程库所引入的一个实现特性是对 ABI（应用程序二进制接口）的支持。这帮助实现了与 LinuxThreads的向后兼容性。这个特性是通过使用 LD_ASSUME_KERNEL 实现的，下面就来介绍这个特性。

 

 Sam对上面的这些描述其实很多也不是很清楚，放在这里作为备份，未来理解多了，慢慢读。

 

GNU_LIBPTHREAD_VERSION宏

大部分现代 Linux 发行版都预装了 LinuxThreads 和NPTL，因此它们提供了一种机制来在二者之间进行切换。要查看您的系统上正在使用的是哪个线程库，请运行下面的命令：

$ getconf GNU_LIBPTHREAD_VERSION

这会产生类似于下面的输出结果：

NPTL 0.34

或者：

linuxthreads-0.10

 

Linux 发行版所使用的线程模型、glibc版本和内核版本

表 1 列出了一些流行的 Linux 发行版，以及它们所采用的线程实现的类型、glibc 库和内核版本。

 

表 1. Linux发行版及其线程实现线程实现C 库发行版内核LinuxThreads 0.7, 0.71 (for libc5)libc 5.xRed Hat 4.2 LinuxThreads 0.7, 0.71 (for glibc 2)glibc 2.0.xRed Hat 5.x LinuxThreads 0.8glibc 2.1.1Red Hat 6.0 LinuxThreads 0.8glibc 2.1.2Red Hat 6.1 and 6.2 LinuxThreads 0.9 Red Hat 7.22.4.7LinuxThreads 0.9glibc 2.2.4Red Hat 2.1 AS2.4.9LinuxThreads 0.10glibc 2.2.93Red Hat 8.02.4.18NPTL 0.6glibc 2.3Red Hat 9.02.4.20NPTL 0.61glibc 2.3.2Red Hat 3.0 EL2.4.21NPTL 2.3.4glibc 2.3.4Red Hat 4.02.6.9LinuxThreads 0.9glibc 2.2SUSE Linux Enterprise Server 7.12.4.18LinuxThreads 0.9glibc 2.2.5SUSE Linux Enterprise Server 82.4.21LinuxThreads 0.9glibc 2.2.5United Linux2.4.21NPTL 2.3.5glibc 2.3.3SUSE Linux Enterprise Server 92.6.5

 

注意，从 2.6.x 版本的内核和 glibc 2.3.3 开始，NPTL所采用的版本号命名约定发生了变化：这个库现在是根据所使用的 glibc 的版本进行编号的。

 

Sam记得好像某篇文章讲，从2.6kernel开始，NPTL支持被加入。只需要glibc用NPTL就可以了。就算我们的系统里装上了NPTL库，也不会影响原来的程序，就算是那些老的程序，即使用了linuxthreads的头文件且在编译，连接的时候使用了linuxthreads的库的程序，我们也能够让它在执行的时候，动态连接到我们的NPTL库。从而发挥NPTL的作用。

 

另外，从GNU libc 2.4开始使用了NPTL方式，但Kernel版本需要 Linux2.6.0以上。

所以判断一个嵌入式平台是否支持NPTL，首先看kernel版本号，如果低于2.6.则肯定不支持NPTL.(因为如果kernel不支持NPTL.则libc再怎么做都没办法)。其次看libc版本号。即/lib/libc.so.xxxx。 另外：截至到目前：uclibc版本为0.9.29。 不支持NPTL。

 

 

所以：

Intel CE3100: 

Kernel Version：２．６．２３

LibC Version: libc-2.7.so

支持NPTL。

 

Intel CE2110：

Kernel Version：２．６．18

LibC Version: libc-2.3.6.so

不支持NPTL。

 

BCM7403：

Kernel Version：2.6.12-4.2

LibC Version: libuClibc-0.9.28.so

不支持NPTL。