Linux线程库.pptVIP

Linux线程库 线程及线程库 当 Linux 最初开发时，在内核中并不能真正支持线程。但是它的确可以通过 clone() 系统调用将进程作为可调度的实体。这个调用创建了调用进程（calling process）的一个拷贝，这个拷贝与调用进程共享相同的地址空间 LinuxThreads 项目使用这个调用来完全在用户空间模拟对线程的支持。不幸的是，这种方法有一些缺点，尤其是在信号处理、调度和进程间同步原语方面都存在问题。另外，这个线程模型也不符合 POSIX 的要求。 线程库的演化 要改进 LinuxThreads，非常明显我们需要内核的支持，并且需要重写线程库 有两个相互竞争的项目开始来满足这些要求。 一个包括 IBM 的开发人员的团队开展了 NGPT（Next-Generation POSIX Threads）项目 同时，Red Hat 的一些开发人员开展了 NPTL 项目。 NGPT 在 2003 年中期被放弃了，把这个领域完全留给了 NPTL。 LinuxThreads 设计细节 线程 将应用程序划分成一个或多个同时运行的任务。 线程与传统的多任务进程 之间的区别在于： 线程共享的是单个进程的状态信息，并会直接共享内存和其他资源。 同一个进程中线程之间的上下文切换通常要比进程之间的上下文切换速度更快。 因此，多线程程序的优点就是它可以比多进程应用程序的执行速度更快。 另外，使用线程我们可以实现并行处理。 这些相对于基于进程的方法所具有的优点推动了 LinuxThreads 的实现。 LinuxThreads 最初的设计相信相关进程之间的上下文切换速度很快，因此每个内核线程足以处理很多相关的用户级线程。这就导致了一对一 线程模型的革命 管理线程 LinuxThreads 非常出名的一个特性就是管理线程（manager thread）。管理线程可以满足以下要求： 系统必须能够响应终止信号并杀死整个进程。 以堆栈形式使用的内存回收必须在线程完成之后进行。因此，线程无法自行完成这个过程。 终止线程必须进行等待，这样它们才不会进入僵尸状态。 线程本地数据的回收需要对所有线程进行遍历；这必须由管理线程来进行。 如果主线程需要调用 pthread_exit()，那么这个线程就无法结束。主线程要进入睡眠状态，而管理线程的工作就是在所有线程都被杀死之后来唤醒这个主线程。 LinuxThreads设计细节 为了维护线程本地数据和内存，LinuxThreads 使用了进程地址空间的高位内存（就在堆栈地址之下） 原语的同步是使用信号 来实现的。例如，线程会一直阻塞，直到被信号唤醒为止在克隆系统的最初设计之下，LinuxThreads 将每个线程都是作为一个具有惟一进程 ID 的进程实现的。终止信号可以杀死所有的线程。LinuxThreads 接收到终止信号之后，管理线程就会使用相同的信号杀死所有其他线程（进程） 根据 LinuxThreads 的设计，如果一个异步信号被发送了，那么管理线程就会将这个信号发送给一个线程。如果这个线程现在阻塞了这个信号，那么这个信号也就会被挂起。这是因为管理线程无法将这个信号发送给进程；相反，每个线程都是作为一个进程在执行。线程之间的调度是由内核调度器来处理的。 设计局限性 LinuxThreads 设计的一些局限性 它使用管理线程来创建线程，并对每个进程所拥有的所有线程进行协调。这增加了创建和销毁线程所需要的开销 由于它是围绕一个管理线程来设计的，因此会导致很多的上下文切换的开销，这可能会妨碍系统的可伸缩性和性能 由于管理线程只能在一个 CPU 上运行，因此所执行的同步操作在 SMP 或 NUMA 系统上可能会产生可伸缩性的问题 由于线程的管理方式，以及每个线程都使用了一个不同的进程 ID，因此 LinuxThreads 与其他与 POSIX 相关的线程库并不兼容 信号用来实现同步原语，这会影响操作的响应时间。另外，将信号发送到主进程的概念也并不存在。因此，这并不遵守 POSIX 中处理信号的方法。 性能、可伸缩、可用性 LinuxThreads 中对信号的处理是按照每线程的原则建立的，而不是按照每进程的原则建立的，这是因为每个线程都有一个独立的进程 ID。由于信号被发送给了一个专用的线程，因此信号是串行化的 —— 也就是说，信号是透过这个线程再传递给其他线程的。这与 POSIX 标准对线程进行并行处理的要求形成了鲜明的对比。 由于 LinuxThreads 中的每个线程都是一个进程，因此用户和组 ID 的信息可能对单个进程中的所有线程来说都不是通用的。例如，一个多线程的 setuid()/setgid() 进程对于不同的线程来说可能都是不同的。 由于每个线程都是一个单独的进程，因此