Linux线程比较：LinuxThreads 和NPTL （5）

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

Java™ 虚拟机（JVM）的支持可能会稍有不同。IBM 的 JVM 可以支持表 1 中 glibc 版本高于 2.1 的大部分发行版。

结束语

LinuxThreads 的限制已经在 NPTL 以及 LinuxThreads 后期的一些版本中得到了克服。例如，最新的 LinuxThreads 实现使用了线程注册来定位线程本地数据；例如在 Intel® 处理器上，它就使用了 %fs 和 %gs 段寄存器来定位访问线程本地数据所使用的虚拟地址。尽管这个结果展示了 LinuxThreads 所采纳的一些修改的改进结果，但是它在更高负载和压力测试中，依然存在很多问题，因为它过分地依赖于一个管理线程，使用它来进行信号处理等操作。

您应该记住，在使用 LinuxThreads 构建库时，需要使用 -D_REENTRANT 编译时标志。这使得库线程是安全的。

最后，也许是最重要的事情，请记住 LinuxThreads 项目的创建者已经不再积极更新它了，他们认为 NPTL 会取代 LinuxThreads。

LinuxThreads 的缺点并不意味着 NPTL 就没有错误。作为一个面向 SMP 的设计，NPTL 也有一些缺点。我曾经看到过在最近的 Red Hat 内核上出现过这样的问题：一个简单线程在单处理器的机器上运行良好，但在 SMP 机器上却挂起了。我相信在 Linux 上还有更多工作要做才能使它具有更好的可伸缩性，从而满足高端应用程序的需求。