剖析Linux 2.6核心移植－－超執行緒篇(zt)

對於大多數應用軟體開發者來說，Linux 2.4和2.6核心家族間的大部分差異對它們沒有直接的影響。大多數核心變化只是為了提高系統效能而已。但也有例外，對某些應用軟體而言，核心和系統的變化對它們的推廣和它們對其它程式和執行緒的管理都具有一定的影響。

2.6核心為使用者帶來了一種新的、改進的超執行緒模式。這種模式是透過NPTL（Native POSIX Thread Library）實施的。新的超執行緒模式的採用對於開發人員、系統執行時間庫（如GNU C庫）、共享應用軟體庫等有著非凡的意義。本文將介紹基本的超執行緒概念，討論已有的Linux超執行緒模式，並著重指出在2.6核心下如何修改已有多執行緒應用軟體。

超執行緒技術

在Linux之類的多程式作業系統中，一個程式生成另一個程式是最基本的概念。最典型的例子是外殼程式，如Bash外殼程式。它是一個標準的Linux命令翻譯程式。外殼程式根據使用者的命令執行相應的應用程式，可以直接啟動多個命令並等待它們完成，也可以將多個命令分開同時執行。

一個程式通常可以透過一組fork（）和exec（）函式呼叫來生成新的程式。初始程式呼叫fork（）函式，產生一個子程式。子程式繼承了母程式的整個執行環境。fork（）函式呼叫將子程式的程式標識（PID）反饋給母程式，同時還包括子程式中的PID.然後，子程式使用exec（）函式呼叫來執行其它的命令，改變繼承來的執行環境。同時，母程式或者迅速退出，或者等待子程式回到其初始狀態。

Linux超執行緒模式

Linux 2.6核心以前所有版本的標準Linux超執行緒庫被稱為LinuxThreads.這種庫可以與不低於GLIBC 2.0版本GNU C庫一起工作，並且與POSIX相容。

在LinuxThreads和Native POSIX Thread Library（NPTL）原始碼的編譯過程中，產生的主要庫是libpthread.so和libpthread.a.為此，LinuxThreads和pthreads名稱過去可以互換使用。但是引入NPTL後，兩者極易發生混淆。本文使用LinuxThreads和NPTL以便明確區分兩個超執行緒庫和它們的功能。

LinuxThreads擁有不同的效能、可伸縮性和可用性限制。LinuxThreads針對單一程式可產生的執行緒數透過一個編譯器設定。此外，它還使用一個程式管理器協調每個程式產生的所有執行緒間的關係。這樣會大大增加執行緒建立和消除佔用的資源。儘管基本上每個執行緒都有獨立的程式ID，但訊號的處理仍是在各個程式中完成的。由於種種原因，在LinuxThreads實施過程中，同時產生並工作的執行緒數量常常會受到限制。這些原因包括核心與使用者空間執行緒間的不對稱關係，缺少執行緒間通訊和分享資源所需的執行緒同步原語等。

Linux的另一超執行緒模式是IBM公司的下一代POSIX執行緒（NGPT）專案。它是一個與LinuxThreads套件一起工作的外部超執行緒庫。但是它可以提供額外的POSIX支援和優於標準LinuxThreads套件的效能。NGPT套件可用於Linux2.4和更早的核心，由於新超執行緒模式的產生，其應用範圍越來越小。

NPTL自從出現2.5核心後便開始逐漸代替LinuxThreads和NGPT.NPTL為Linux系統提供更高效能的超執行緒支援，並且可提供多執行緒企業應用軟體所需的基本功能，此外還可提供高容量、高載入量的網路和郵件伺服器等。NPTL的開發是2.5核心開發程式的一部分，並且與Linux執行時元件（如GLIBC）整合在一起，具備了眾多優勢的NPTL是未來Linux執行緒的發展方向。

一些Linux系統生產商（如Red Hat公司）已開始向舊版本核心追加NPTL，甚至透過一個環境變數為特定的可選程式建立超執行緒環境。在支援此功能的系統中，變數可以透過下面的命令來設定：

# export LD_ASSUME_KERNEL=2.4.1

對於那些原本依靠LinuxThreads模式的已有應用軟體來說，要想繼續在NPTL環境下工作，這是一個比較聰明的辦法，但同時也是一個權宜之計。為了能更好的利用NPTL的設計和效能優勢，使用者需要對使用超執行緒模式的現有應用軟體的程式碼進行升級。

應用軟體的重編譯

儘管有許多應用軟體從2.4核心到2.6核心移植過程中不需要重新編譯，但是大多數多執行緒應用軟體的NPTL附加技術需要進行略微的修改。

那些需要重新編譯的應用軟體也許會受到升級編譯程式的影響。這些編譯程式一般都包含在基於2.6核心的Linux套件中，例如TimeSys Linux系統。TimeSys在推出2.6 Reference Distributions的同時捆綁了GCC的3.3.2版本的C和C++編譯程式，並使用升級版本的binutils套件彌補標準Linux工具鏈的不足。

使用基於2.6的核心並不意味著使用者已自動使用NPTL。為了決定系統使用的超執行緒庫，使用者可以執行下面的命令，對GNU_LIBPTHREAD_VERSION環境變數進行檢測，如下所示:

# getconf GNU_LIBPTHREAD_VERSIONlinuxthreads-0.10
If your system uses the NPTL, the command would return the value of NPTL 
that your system was using,as in the following example:
# getconf GNU_LIBPTHREAD_VERSIONnptl-0.60

如果使用者正在建立適用於2.6核心的工具鏈，那麼必須確定已經在2.6核心上建立了擁有NPTL技術支援的“工具鏈”。此外，使用者還需要較新的C語言庫原始碼。例如，如果使用者正在建立擁有NPTL支援的GBLIC，那麼就要使用2.3.3版本以上的GBLIC原始碼。為GBLIC提供NPTL支援的過程與提供LinuxThreads支援的過程十分相似。不同的是在設定GBLIC時，使用“--enable-add-ons=nptl”設定選項，而不是“--enable-add-ons=linuxthreads”。使用者還需要一個新版本的GCC（3.3.2或更高版本）和支援框架資訊呼叫（CFI）指令的binutils（2.14.90.0.7或更高版本）。

一般情況下，如果使用者的應用軟體使用較早版本的GCC進行編譯，使用者也許會注意到報警資訊、原始碼尺寸等不同之處。此外，GCC編譯程式和剩餘工具鏈提供的選項也不盡相同。當使用者在對嵌入式應用軟體進行重新編譯時，必須瞭解程式碼尺寸有增大的潛在趨勢。使用者也許需要充分利用額外或新的最佳化選項，以便在資源有限的環境下，繼續適應現有的應用軟體。版本越新的GCC越能適應各種C或C++規格，並提高了對應用軟體程式碼的要求。一般情況下，從升級編譯程式中獲得的新報警資訊對消除潛在缺陷是十分有用的。

為NPTL升級應用軟體

2.4核心的超執行緒支援和NPTL支援間的變化為設計和效能的提高提供了廣闊的改進空間。在2.4核心下，NPTL與POSIX規格的適應程度要比與LinuxThreads套件的適應程式高得多。NPTL還支援諸如mutexes之類的功能。最後，NPTL要比2.4核心的超執行緒支援更有效。

在向NPTL移植過程中，使用者需要對應用軟體邏輯作更復雜的修改。這些修改與NPTL對POSIX訊號和訊號處理的支援有關。LinuxThreads實施一般性的Unix型執行緒，但是它卻受各種實施細節的限制。因為NPTL是一種與POSIX相適應的超執行緒實施方案，所以它在程式間訊號處理和執行緒間訊號處理方面表現得較為優秀。在NPTL中，訊號可以由一個執行緒傳給另一執行緒，而不只是程式間的傳遞。訊號也可以使用引數來完成執行緒間的資訊傳遞。

在使用NPTL時，使用者還需要對識別具體執行緒的現有程式碼進行修改。在LinuxThreads下，每個執行緒都擁有惟一的程式ID（PID）。而現在，母程式下的各個執行緒都共享同一PID，因此getpid()函式將為程式中的所有執行緒返回同一PID。在NPTL下，一個執行緒的執行緒ID在使用時必須是唯一的，這樣才能對每個執行緒進行正確的識別。

對執行緒ID和程式ID進行的修改還意味著程式產生的方式現在需要針對執行緒而進行。例如，exec()函式目前可以對執行緒進行操作，因此一個執行緒可以繼承呼叫者的PID。只有當整個程式結束時，多執行緒程式的母程式才知道某一子程式已經執行完畢。有關執行緒的變化還會對相關fork()呼叫產生影響。例如，在pthread_at_fork()函式中登記的函式在vfork()發生時將無法再繼續執行。

除了對執行緒識別的內部構件進行修改外，NPTL廢除了LinuxThreads的管理者執行緒的概念，簡化了程式和執行緒間的關係。這些也許需要對應用軟體做適當的修改。

最後，使用新超執行緒庫意味著在LinuxThreads可以使用的一些超執行緒函式在NPTL下將無法繼續使用。例如pthread_kill_other_threads_np()函式便無法繼續使用。該函式將的作用是啟用與POSIX相適應的exec()函式，而在NPTL下，exec()函式無法再與POSIX相適應。

總結

修改計算機執行的核心並不是件容易的事，但是它也不是不可能完成的任務。以上五篇文章中，我們著重介紹了2.6核心設定中遇到的主要問題、升級硬體驅動程式、移植桌面和定製系統以及升級應用軟體。TimeSys公司的2.6 Reference Distribution是第一款應用於PPC系統的Linux套件。諸如TimeSys公司的TimeStorm IDE和TimeStorm Linux系統開發套件(LDS)之類的高質量商業軟體可以幫助我們移植所有的Linux核心、硬體驅動程式、應用軟體。此外，它們還可以幫助我們對系統進行配置，以便充分發揮2.6核心、升級套件、穿線技術等軟體技術的作用。

Linux作為開放系統運動中最耀眼的明星，積極投身於軟體產業的變革。Linux核心作為所有Linux系統的核心，在發展過程中不斷地引入新技術，改善效能、可伸縮性、技術支援和可用性。2.6核心擴充了Linux系統的應用範圍，從PDA、程式控制系統、機頂盒到企業伺服器處處都能看到它的身影。Linux系統的成本、動力和技術支援優勢在今天的商業市場和飛速發展的技術環境中顯得更加明顯。