Linux 執行緒模式的比較：LinuxThreads 和 NPTL

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

LinuxThreads 項目最初將多線程的概念引入了 Linux，但是 LinuxThreads 並不遵守 POSIX 線程標準。儘管更新的 Native POSIX Thread Library（NPTL）庫填補了一些空白，但是這仍然存在一些問題。本文為那些需要將自己的應用程式從 LinuxThreads 移植到 NPTL 上或者只是希望理解有何區別的開發人員介紹這兩種 Linux 執行緒模式之間的區別。

當 Linux 最初開發時，在核心中並不能真正支援線程。但是它的確可以通過 clone() 系統調用將進程作為可調度的實體。這個調用建立了調用進程（calling process）的一個拷貝，這個拷貝與調用進程共用相同的地址空間。LinuxThreads 項目使用這個調用來完全在使用者空間類比對線程的支援。不幸的是，這種方法有一些缺點，尤其是在訊號處理、調度和進程間同步原語方面都存在問題。另外，這個執行緒模式也不符合 POSIX 的要求。

要改進 LinuxThreads，非常明顯我們需要核心的支援，並且需要重寫線程庫。有兩個相互競爭的項目開始來滿足這些要求。一個包括 IBM 的開發人員的團隊開展了 NGPT（Next-Generation POSIX Threads）項目。同時，Red Hat 的一些開發人員開展了 NPTL 項目。NGPT 在 2003 年中期被放棄了，把這個領域完全留給了 NPTL。

儘管從 LinuxThreads 到 NPTL 看起來似乎是一個必然的過程，但是如果您正在為一個曆史悠久的 Linux 發行版維護一些應用程式，並且計劃很快就要進行升級，那麼如何遷移到 NPTL 上就會變成整個移植過程中重要的一個部分。另外，我們可能會希望瞭解二者之間的區別，這樣就可以對自己的應用程式進行設計，使其能夠更好地利用這兩種技術。

本文詳細介紹了這些執行緒模式分別是在哪些發行版上實現的。

LinuxThreads 設計細節

線程 將應用程式劃分成一個或多個同時啟動並執行任務。線程與傳統的多任務進程 之間的區別在於：線程共用的是單個進程的狀態資訊，並會直接共用記憶體和其他資源。同一個進程中線程之間的環境切換通常要比進程之間的環境切換速度更快。因此，多線程程式的優點就是它可以比多進程應用程式的執行速度更快。另外，使用線程我們可以實現平行處理。這些相對於基於進程的方法所具有的優點推動了 LinuxThreads 的實現。

LinuxThreads 最初的設計相信相關進程之間的環境切換速度很快，因此每個核心線程足以處理很多相關的使用者級線程。這就導致了一對一 執行緒模式的革命。

讓我們來回顧一下 LinuxThreads 設計細節的一些基本理念：

• LinuxThreads 非常出名的一個特性就是管理線程（manager thread）。管理線程可以滿足以下要求：

  • 系統必須能夠響應終止訊號並殺死整個進程。
  • 以堆棧形式使用的記憶體回收必須線上程完成之後進行。因此，線程無法自行完成這個過程。
  • 終止線程必須進行等待，這樣它們才不會進入殭屍狀態。
  • 執行緒區域資料的回收需要對所有線程進行遍曆；這必須由管理線程來進行。
  • 如果主線程需要調用 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。
• 由於計算執行緒區域資料的方法是基於堆棧地址的位置的，因此對於這些資料的訪問速度都很慢。另外一個缺點是使用者無法可信地指定堆棧的大小，因為使用者可能會意外地將堆棧地址映射到本來要為其他目的所使用的地區上了。按需增長（grow on 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 實現的，下面就來介紹這個特性。

 

回頁首

 

LD_ASSUME_KERNEL 環境變數

正如上面介紹的一樣，ABI 的引入使得可以同時支援 NPTL 和 LinuxThreads 模型。基本上來說，這是通過 ld （一個動態連結器/載入器）來進行處理的，它會決定動態連結到哪個運行時線程庫上。

舉例來說，下面是 WebSphere Application Server 對這個變數所使用的一些通用設定；您可以根據自己的需要進行適當的設定：

• LD_ASSUME_KERNEL=2.4.19：這會覆蓋 NPTL 的實現。這種實現通常都表示使用標準的 LinuxThreads 模型，並啟用浮動堆棧的特性。
• LD_ASSUME_KERNEL=2.2.5：這會覆蓋 NPTL 的實現。這種實現通常都表示使用 LinuxThreads 模型，同時使用固定堆棧大小。

我們可以使用下面的命令來設定這個變數：

export LD_ASSUME_KERNEL=2.4.19

注意，對於任何 LD_ASSUME_KERNEL 設定的支援都取決於目前所支援的線程庫的 ABI 版本。例如，如果線程庫並不支援 2.2.5 版本的 ABI，那麼使用者就不能將 LD_ASSUME_KERNEL 設定為 2.2.5。通常，NPTL 需要 2.4.20，而 LinuxThreads 則需要 2.4.1。

如果您正啟動並執行是一個啟用了 NPTL 的 Linux 發行版，但是應用程式卻是基於 LinuxThreads 模型來設計的，那麼所有這些設定通常都可以使用。

 

回頁首

 

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.x	Red Hat 4.2
LinuxThreads 0.7, 0.71 (for glibc 2)	glibc 2.0.x	Red Hat 5.x
LinuxThreads 0.8	glibc 2.1.1	Red Hat 6.0
LinuxThreads 0.8	glibc 2.1.2	Red Hat 6.1 and 6.2
LinuxThreads 0.9		Red Hat 7.2	2.4.7
LinuxThreads 0.9	glibc 2.2.4	Red Hat 2.1 AS	2.4.9
LinuxThreads 0.10	glibc 2.2.93	Red Hat 8.0	2.4.18
NPTL 0.6	glibc 2.3	Red Hat 9.0	2.4.20
NPTL 0.61	glibc 2.3.2	Red Hat 3.0 EL	2.4.21
NPTL 2.3.4	glibc 2.3.4	Red Hat 4.0	2.6.9
LinuxThreads 0.9	glibc 2.2	SUSE Linux Enterprise Server 7.1	2.4.18
LinuxThreads 0.9	glibc 2.2.5	SUSE Linux Enterprise Server 8	2.4.21
LinuxThreads 0.9	glibc 2.2.5	United Linux	2.4.21
NPTL 2.3.5	glibc 2.3.3	SUSE Linux Enterprise Server 9	2.6.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 上還有更多工作要做才能使它具有更好的延展性，從而滿足高端應用程式的需求。

 

更多關於LinuxThreads的介紹請參考：

 

http://wenku.baidu.com/view/3d588bef5ef7ba0d4a733bce.html