自從多線程編程的概念出現在 Linux 中以來，Linux 多線應用的發展總是與兩個問題脫不開干系：兼容性、效率。本文從線程模型入手，通過分析目前 Linux 平台上最流行的 LinuxThreads 線程庫的實現及其不足，描述了 Linux 社區是如何看待和解決兼容性和效率這兩個問題的。
一.基礎知識：線程和進程
按照教科書上的定義，進程是資源管理的最小單位，線程是程序執行的最小單位。在操作系統設計上，從進程演化出線程，最主要的目的就是更好的支持SMP以及減小（進程/線程）上下文切換開銷。
無論按照怎樣的分法，一個進程至少需要一個線程作為它的指令執行體，進程管理著資源（比如cpu、內存、文件等等），而將線程分配到某個cpu上執行。一個進程當然可以擁有多個線程，此時，如果進程運行在SMP機器上，它就可以同時使用多個cpu來執行各個線程，達到最大程度的並行，以提高效率；同時，即使是在單cpu的機器上，采用多線程模型來設計程序，正如當年采用多進程模型代替單進程模型一樣，使設計更簡潔、功能更完備，程序的執行效率也更高，例如采用多個線程響應多個輸入，而此時多線程模型所實現的功能實際上也可以用多進程模型來實現，而與後者相比，線程的上下文切換開銷就比進程要小多了，從語義上來說，同時響應多個輸入這樣的功能，實際上就是共享了除cpu以外的所有資源的。
針對線程模型的兩大意義，分別開發出了核心級線程和用戶級線程兩種線程模型，分類的標准主要是線程的調度者在核內還是在核外。前者更利於並發使用多處理器的資源，而後者則更多考慮的是上下文切換開銷。在目前的商用系統中，通常都將兩者結合起來使用，既提供核心線程以滿足smp系統的需要，也支持用線程庫的方式在用戶態實現另一套線程機制，此時一個核心線程同時成為多個用戶態線程的調度者。正如很多技術一樣，"混合"通常都能帶來更高的效率，但同時也帶來更大的實現難度，出於"簡單"的設計思路，Linux從一開始就沒有實現混合模型的計劃，但它在實現上采用了另一種思路的"混合"。
在線程機制的具體實現上，可以在操作系統內核上實現線程，也可以在核外實現，後者顯然要求核內至少實現了進程，而前者則一般要求在核內同時也支持進程。核心級線程模型顯然要求前者的支持，而用戶級線程模型則不一定基於後者實現。這種差異，正如前所述，是兩種分類方式的標准不同帶來的。
當核內既支持進程也支持線程時，就可以實現線程-進程的"多對多"模型，即一個進程的某個線程由核內調度，而同時它也可以作為用戶級線程池的調度者，選擇合適的用戶級線程在其空間中運行。這就是前面提到的"混合"線程模型，既可滿足多處理機系統的需要，也可以最大限度的減小調度開銷。絕大多數商業操作系統（如Digital Unix、Solaris、Irix）都采用的這種能夠完全實現POSIX1003.1c標准的線程模型。在核外實現的線程又可以分為"一對一"、"多對一"兩種模型，前者用一個核心進程（也許是輕量進程）對應一個線程，將線程調度等同於進程調度，交給核心完成，而後者則完全在核外實現多線程，調度也在用戶態完成。後者就是前面提到的單純的用戶級線程模型的實現方式，顯然，這種核外的線程調度器實際上只需要完成線程運行棧的切換，調度開銷非常小，但同時因為核心信號（無論是同步的還是異步的）都是以進程為單位的，因而無法定位到線程，所以這種實現方式不能用於多處理器系統，而這個需求正變得越來越大，因此，在現實中，純用戶級線程的實現，除算法研究目的以外，幾乎已經消失了。
Linux內核只提供了輕量進程的支持，限制了更高效的線程模型的實現，但Linux著重優化了進程的調度開銷，一定程度上也彌補了這一缺陷。目前最流行的線程機制LinuxThreads所采用的就是線程-進程"一對一"模型，調度交給核心，而在用戶級實現一個包括信號處理在內的線程管理機制。Linux-LinuxThreads的運行機制正是本文的描述重點。
