注：这篇文章转自网络，虽然Linux从内核2.6开始，多线程已使用NPTL技术，但是这篇文章对我们理解多线程技术还是挺有用的

例如我的ubuntu 系统：使用的就是NPTL

~/myProc$ getconf GNU_LIBPTHREAD_VERSION
NPTL 2.19

LinuxThreads

Linux内核对多进程和多线程的支持方式：

线程机制支持并发程序设计技术，在多处理器上能真正保证并行处理。而在linux实现线程很特别，linux把所有的线程都当作进程实现。linux下线 程看起来就像普通进程(只是该进程和其他进程共享资源，如地址空间)。上述机制与Microsoft windows或是Sun Solaris实现差异很大。

Linux的线程实现是在核外进行的，核内提供的是创建进程的接口do_fork()。内核提供了两个系统调用__clone()和fork()，最终都 用不同的参数调用do_fork()核内API。 do_fork() 提供了很多参数，包括CLONE_VM（共享内存空间）、CLONE_FS（共享文件系统信息）、CLONE_FILES（共享文件描述符表）、 CLONE_SIGHAND（共享信号句柄表）和CLONE_PID（共享进程ID，仅对核内进程，即0号进程有效）。当使用fork系统调用产生多进程 时，内核调用do_fork()不使用任何共享属性，进程拥有独立的运行环境。当使用pthread_create()来创建线程时，则最终设置了所有这 些属性来调用__clone()，而这些参数又全部传给核内的do_fork()，从而创建的”进程”拥有共享的运行环境，只有栈是独立的，由 __clone()传入。

即：Linux下不管是多线程编程还是多进程编程，最终都是用do_fork实现的 多进程编程，只是进程创建时的参数不同，从而导致有不同的共享环境。Linux线程在核内是以轻量级进程的形式存在的，拥有独立的进程表项，而所有的创 建、同步、删除等操作都在核外pthread库中进行。pthread 库使用一个管理线程（__pthread_manager() ，每个进程独立且唯一）来管理线程的创建和终止，为线程分配线程ID，发送线程相关的信号，而主线程pthread_create()） 的调用者则通过管道将请求信息传给管理线程。

很多朋友都说使用多线程的好处是资源占用少，其隐含之意就是说进程占用资源比线程多，对吧？但实际上Linux下多进程是否就真的点用很多资源呢？ 暂且不说进程是否比线程占用资源多，就进程占用资源的多少情况而言，Linux确实是做得相当节省的。产生一个多进程时肯定是要产生的一点内存是要复制进 程表项，即一个task_struct结构，但这个结构本身做得相当小巧。其它对于一个进程来说必须有的数据段、代码段、堆栈段是不是全盘复制呢？对于多 进程来说，代码段是肯定不用复制的，因为父进程和各子进程的代码段是相同的，数据段和堆栈段呢？也不一定，因为在Linux里广泛使用的一个技术叫 copy-on-write，即写时拷贝。copy-on-write意味着什么呢？意味着资源节省，假设有一个变量x在父进程里存在，当这个父进程创建 一个子进程或多个子进程时这个变量x是否复制到了子进程的内存空间呢？不会的，子进程和父进程使用同一个内存空间的变量，但当子进程或父进程要改变变量x 的值时就会复制该变量，从而导致父子进程里的变量值不同。父子进程变量是互不影响的，由于父子进程地址空间是完全隔开的，变量的地址可以是完全相同的。

Linux的”线程”和”进程”实际上处于一个调度层次，共享一个进程标识符空间，这种限制使得不可能在Linux上实现完全意义上的POSIX线程机 制，因此众多的Linux线程库实现尝试都只能尽可能实现POSIX的绝大部分语义，并在功能上尽可能逼近。Linux进程的创建是非常迅速的。内核设计 与实现一书中甚至指出Linux创建进程的速度和其他针对线程优化的操作系统（Windows,Solaris）创建线程的速度相比，测试结果非常的好， 也就是说创建速度很快。由于异步信号是内核以进程为单位分发的，而LinuxThreads的每个线程对内核来说都是一个进程，且没有实现”线程组”，因 此，某些语义不符合POSIX标准，比如没有实现向进程中所有线程发送信号，README对此作了说明。LinuxThreads中的线程同步很大程度上 是建立在信号基础上的，这种通过内核复杂的信号处理机制的同步方式，效率一直是个问题。LinuxThreads 的问题，特别是兼容性上的问题，严重阻碍了Linux上的跨平台应用（如Apache）采用多线程设计，从而使得Linux上的线程应用一直保持在比较低 的水平。在Linux社区中，已经有很多人在为改进线程性能而努力，其中既包括用户级线程库，也包括核心级和用户级配合改进的线程库。目前最为人看好的有 两个项目，一个是RedHat公司牵头研发的NPTL（Native Posix Thread Library），另一个则是IBM投资开发的NGPT（Next Generation Posix Threading），二者都是围绕完全兼容POSIX 1003.1c，同时在核内和核外做工作以而实现多对多线程模型。这两种模型都在一定程度上弥补了LinuxThreads的缺点，且都是重起炉灶全新设 计的。

另外可以参考这篇文章

http://www.ibm.com/developerworks/cn/linux/l-threading.html

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。
• 由于计算线程本地数据的方法是基于堆栈地址的位置的，因此对于这些数据的访问速度都很慢。另外一个缺点是用户无法可信地指定堆栈的大小，因为用户可能会意外地将堆栈地址映射到本来要为其他目的所使用的区域上了。按需增长（grow on demand） 的概念（也称为浮动堆栈 的概念）是在 2.4.10 版本的 Linux 内核中实现的。在此之前，LinuxThreads 使用的是固定堆栈