Linux程序、線程模型，LWP，pthread

一．定義 關于程序、輕量級程序、線程、使用者線程、核心線程的定義，這個很容易找到，但是看完之後你可以說你懂了，但實際上你真的明白了麼？ 在現代作業系統中，程序支援多線程。程序是資源管理的最小單元；而線程是程式執行的最小單元。一個程序的組成實體可以分為兩大部分：線程集合和資源集合。程序中的線程是動态的對象；代表了程序指令的執行。資源，包括位址空間、打開的檔案、使用者資訊等等，由程序内的線程共享。線程有自己的私有資料：程式計數器，棧空間以及寄存器。 傳統程序的缺點 現實中有很多需要并發處理的任務，如資料庫的伺服器端、網絡伺服器、大容量計算等。一個任務是一個程序，傳統的UNIX程序是單線程（執行流）的，單線程意味着程式必須是順序執行，單個任務不能并發；既在一個時刻隻能運作在一個處理器上，是以不能充分利用多處理器架構的計算機。如果采用多程序的方法，即把一個任務用多個程序解決，則有如下問題： a. fork一個子程序的消耗是很大的，fork是一個昂貴的系統調用，即使使用現代的寫時複制(copy-on-write)技術。 b. 各個程序擁有自己獨立的位址空間，程序間的協作需要複雜的IPC技術，如消息傳遞和共享記憶體等。 多線程的優缺點 線程：其實可以先簡單了解成cpu的一個執行流，指令序列。多支援多線程的程式(程序)可以取得真正的并行(parallelism)，且由于共享程序的代碼和全局資料，故線程間的通信是友善的。它的缺點也是由于線程共享程序的位址空間，是以可能會導緻競争，是以對某一塊有多個線程要通路的資料需要一些同步技術。 輕量級程序LWP     既然稱作輕量級程序，可見其本質仍然是程序，與普通程序相比，LWP與其它程序共享所有（或大部分）邏輯位址空間和系統資源，一個程序可以建立多個LWP，這樣它們共享大部分資源；LWP有它自己的程序辨別符，并和其他程序有着父子關系；這是和類Unix作業系統的系統調用vfork()生成的程序一樣的。LWP由核心管理并像普通程序一樣被排程。Linux核心是支援LWP的典型例子。Linux核心在 2.0.x版本就已經實作了輕量程序，應用程式可以通過一個統一的clone()系統調用接口，用不同的參數指定建立輕量程序還是普通程序，通過參數決定子程序和父程序共享的資源種類和數量，這樣就有了輕重之分。在核心中， clone()調用經過參數傳遞和解釋後會調用do_fork()，這個核内函數同時也是fork()、vfork()系統調用的最終實作。 在大多數系統中，LWP與普通程序的差別也在于它隻有一個最小的執行上下文和排程程式所需的統計資訊，而這也是它之是以被稱為輕量級的原因。 因為LWP之間共享它們的大部分資源，是以它在某些應用程式就不适用了；這個時候就要使用多個普通的程序了。例如，為了避免記憶體洩漏（a process can be replaced by another one）和實作特權分隔（processes can run under other credentials and have other permissions）。 使用者線程 這裡的使用者線程指的是完全建立在使用者空間的線程庫，使用者線程的建立，同步，銷毀，排程完全在使用者空間完成，不需要核心的幫助。是以這種線程的操作是極其快速的且低消耗的。 上圖是最初的一個使用者線程模型，從中可以看出，程序中包含線程，使用者線程在使用者空間中實作，核心并沒有直接對使用者線程程序排程，核心的排程對象和傳統程序一樣，還是程序本身，核心并不知道使用者線程的存在。使用者線程之間的排程由在使用者空間實作的線程庫實作。 這種模型對應着恐龍書中提到的多對一線程模型，其缺點是一個使用者線程如果阻塞在系統調用中，則整個程序都将會阻塞。 核心線程 使用者态線程和核心态線程；主要的區分就是“誰來管理”線程，使用者态是使用者管理，核心态是核心管理（但肯定要提供一些API，例如建立）。 簡單對比兩者優劣勢： 1）可移植性：因為ULT完全在使用者态實作線程，是以也就和具體的核心沒有什麼關系，可移植性方面ULT略勝一籌； 2）可擴充性：ULT是由使用者控制的，是以擴充也就容易；相反，KLT擴充就很不容易，基本上隻能受制于具體的作業系統核心； 3）性能：由于ULT的線程是在使用者态，對應的核心部分還是一個程序，是以ULT就沒有辦法利用多處理器的優勢，而KLT就可以通過排程将線程分布在多個處理上運作，這樣KLT的性能高得多；另外，一個ULT的線程阻塞，所有的線程都阻塞，而KLT一個線程阻塞不會影響其它線程。 4）程式設計複雜度：ULT的所有管理工作都要由使用者來完成，而KLT僅僅需要調用API接口，是以ULT要比KLT複雜的多。 小結          其實最初根本沒有線程的概念，隻有程序，一個任務一個程序一個執行流，多任務處理機就是多程序。後來提出線程的概念，但是要如何去實作，這裡就有很多種實作方法了，文章看到這裡，可以想到兩種實作方法，一種就是上面所說的使用者線程的方法，其優缺點上文以簡述；再有就是用輕量級程序去模拟，即我們可以把LWP看成是一個線程。就應為這個使得線程和程序的概念混淆了，至少我覺得很多人其實根本就不知道，至少我以前不知道，有人說系統排程機關是程序，又有人說是線程，其實系統排程的機關一直就沒有改變，隻是後來部分線程和程序的界限模糊了，至少上文中的使用者線程絕對不是排程對象，LWP模拟的線程卻是排程對象。 二．Linux線程發展 這個對于了解Linux多線程很有幫助，可惜《深入了解Linux核心》這本書隻字未提，根本沒講Linux多線程的機理，至少我沒看懂。 一直以來, linux核心并沒有線程的概念. 每一個執行實體都是一個task_struct結構, 通常稱之為程序. Linux核心在 2.0.x版本就已經實作了輕量程序，應用程式可以通過一個統一的clone()系統調用接口，用不同的參數指定建立輕量程序還是普通程序。在核心中， clone()調用經過參數傳遞和解釋後會調用do_fork()，這個核内函數同時也是fork()、vfork()系統調用的最終實作。後來為了引入多線程，Linux2.0~2.4實作的是俗稱LinuxThreads的多線程方式，到了2.6，基本上都是NPTL的方式了。下面我們分别介紹。 模型一 ：LinuxThreads      注：以下内容主要參考“楊沙洲 (mailto:[email protected]?subject=Linux 線程實作機制分析&[email protected])國防科技大學計算機學院”的“Linux 線程實作機制分析”。 linux 2.6以前, pthread線程庫對應的實作是一個名叫linuxthreads的lib.這種實作本質上是一種LWP的實作方式，即通過輕量級程序來模拟線程，核心并不知道有線程這個概念，在核心看來，都是程序。 Linux采用的“一對一”的線程模型，即一個LWP對應一個線程。這個模型最大的好處是線程排程由核心完成了，而其他線程操作（同步、取消）等都是核外的線程庫函數完成的。 linux上的線程就是基于輕量級程序, 由使用者态的pthread庫實作的.使用pthread以後, 在使用者看來, 每一個task_struct就對應一個線程, 而一組線程以及它們所共同引用的一組資源就是一個程序.但是, 一組線程并不僅僅是引用同一組資源就夠了, 它們還必須被視為一個整體. 對此, POSIX标準提出了如下要求: 1, 檢視程序清單的時候, 相關的一組task_struct應當被展現為清單中的一個節點; 2, 發送給這個"程序"的信号(對應kill系統調用), 将被對應的這一組task_struct所共享, 并且被其中的任意一個"線程"處理; 3, 發送給某個"線程"的信号(對應pthread_kill), 将隻被對應的一個task_struct接收, 并且由它自己來處理; 4, 當"程序"被停止或繼續時(對應SIGSTOP/SIGCONT信号), 對應的這一組task_struct狀态将改變; 5, 當"程序"收到一個緻命信号(比如由于段錯誤收到SIGSEGV信号), 對應的這一組task_struct将全部退出; 6, 等等(以上可能不夠全); 在LinuxThreads中，專門為每一個程序構造了一個管理線程，負責處理線程相關的管理工作。當程序第一次調用pthread_create()建立一個線程的時候就會建立并啟動管理線程。然後管理線程再來建立使用者請求的線程。也就是說，使用者在調用pthread_create後，先是建立了管理線程，再由管理線程建立了使用者的線程。 linuxthreads利用前面提到的輕量級程序來實作線程, 但是對于POSIX提出的那些要求,linuxthreads除了第5點以外, 都沒有實作(實際上是無能為力): 1, 如果運作了A程式, A程式建立了10個線程, 那麼在shell下執行ps指令時将看到11個A程序, 而不是1個(注意, 也不是10個, 下面會解釋); 2, 不管是kill還是pthread_kill, 信号隻能被一個對應的線程所接收; 3, SIGSTOP/SIGCONT信号隻對一個線程起作用; 還好linuxthreads實作了第5點, 我認為這一點是最重要的. 如果某個線程"挂"了, 整個程序還在若無其事地運作着, 可能會出現很多的不一緻狀态. 程序将不是一個整體, 而線程也不能稱為線程. 或許這也是為什麼linuxthreads雖然與POSIX的要求差距甚遠, 卻能夠存在, 并且還被使用了好幾年的原因吧~ 但是, linuxthreads為了實作這個"第5點", 還是付出了很多代價, 并且創造了linuxthreads本身的一大性能瓶頸. 接下來要說說, 為什麼A程式建立了10個線程, 但是ps時卻會出現11個A程序了. 因為linuxthreads自動建立了一個管理線程. 上面提到的"第5點"就是靠管理線程來實作的. 當程式開始運作時, 并沒有管理線程存在(因為盡管程式已經連結了pthread庫, 但是未必會使用多線程). 程式第一次調用pthread_create時, linuxthreads發現管理線程不存在, 于是建立這個管理線程. 這個管理線程是程序中的第一個線程(主線程)的兒子. 然後在pthread_create中, 會通過pipe向管理線程發送一個指令, 告訴它建立線程. 即是說, 除主線程外, 所有的線程都是由管理線程來建立的, 管理線程是它們的父親. 于是, 當任何一個子線程退出時, 管理線程将收到SIGUSER1信号(這是在通過clone建立子線程時指定的). 管理線程在對應的sig_handler中會判斷子線程是否正常退出, 如果不是, 則殺死所有線程, 然後自殺. 那麼, 主線程怎麼辦呢? 主線程是管理線程的父親, 其退出時并不會給管理線程發信号. 于是, 在管理線程的主循環中通過getppid檢查父程序的ID号, 如果ID号是1, 說明父親已經退出, 并把自己托管給了init程序(1号程序). 這時候, 管理線程也會殺掉所有子線程, 然後自殺. 可見, 線程的建立與銷毀都是通過管理線程來完成的, 于是管理線程就成了linuxthreads的一個性能瓶頸. 建立與銷毀需要一次程序間通信, 一次上下文切換之後才能被管理線程執行, 并且多個請求會被管理線程串行地執行. 這種通過LWP的方式來模拟線程的實作看起來還是比較巧妙的，但也存在一些比較嚴重的問題： 1）線程ID和程序ID的問題 按照POSIX的定義，同一程序的所有的線程應該共享同一個程序和父程序ID，而Linux的這種LWP方式顯然不能滿足這一點。 2）信号處理問題 異步信号是以程序為機關分發的，而Linux的線程本質上每個都是一個程序，且沒有程序組的概念，是以某些預設信号難以做到對所有線程有效，例如SIGSTOP和SIGCONT，就無法将整個程序挂起，而隻能将某個線程挂起。 3）線程總數問題 LinuxThreads将每個程序的線程最大數目定義為1024，但實際上這個數值還受到整個系統的總程序數限制，這又是由于線程其實是核心程序。 4)管理線程問題 管理線程容易成為瓶頸，這是這種結構的通病；同時，管理線程又負責使用者線程的清理工作，是以，盡管管理線程已經屏蔽了大部分的信号，但一旦管理線程死亡，使用者線程就不得不手工清理了，而且使用者線程并不知道管理線程的狀态，之後的線程建立等請求将無人處理。 5)同步問題 LinuxThreads中的線程同步很大程度上是建立在信号基礎上的，這種通過核心複雜的信号處理機制的同步方式，效率一直是個問題。 6）其他POSIX相容性問題 Linux中很多系統調用，按照語義都是與程序相關的，比如nice、setuid、setrlimit等，在目前的LinuxThreads中，這些調用都僅僅影響調用者線程。 7）實時性問題 線程的引入有一定的實時性考慮，但LinuxThreads暫時不支援，比如排程選項，目前還沒有實作。不僅LinuxThreads如此，标準的Linux在實時性上考慮都很少 模型二：NPTL 到了linux 2.6, glibc中有了一種新的pthread線程庫--NPTL(Native POSIX Threading Library). 本質上來說，NPTL還是一個LWP的實作機制，但相對原有LinuxThreads來說，做了很多的改進。下面我們看一下NPTL如何解決原有LinuxThreads實作機制的缺陷 NPTL實作了前面提到的POSIX的全部5點要求. 但是, 實際上, 與其說是NPTL實作了, 不如說是linux核心實作了. 在linux 2.6中, 核心有了線程組的概念, task_struct結構中增加了一個tgid(thread group id)字段. 如果這個task是一個"主線程", 則它的tgid等于pid, 否則tgid等于程序的pid(即主線程的pid). 在clone系統調用中, 傳遞CLONE_THREAD參數就可以把新程序的tgid設定為父程序的tgid(否則新程序的tgid會設為其自身的pid). 類似的XXid在task_struct中還有兩 個：task->signal->pgid儲存程序組的打頭程序的pid、task->signal->session儲存會話 打頭程序的pid。通過這兩個id來關聯程序組和會話。 有了tgid, 核心或相關的shell程式就知道某個tast_struct是代表一個程序還是代表一個線程, 也就知道在什麼時候該展現它們, 什麼時候不該展現(比如在ps的時候, 線程就不要展現了). 而getpid(擷取程序ID)系統調用傳回的也是tast_struct中的tgid, 而tast_struct中的pid則由gettid系統調用來傳回. 在執行ps指令的時候不展現子線程，也是有一些問題的。比如程式a.out運作時，建立 了一個線程。假設主線程的pid是10001、子線程是10002（它們的tgid都是10001）。這時如果你kill 10002，是可以把10001和10002這兩個線程一起殺死的，盡管執行ps指令的時候根本看不到10002這個程序。如果你不知道linux線程背 後的故事，肯定會覺得遇到靈異事件了。 為了應付"發送給程序的信号"和"發送給線程的信号", task_struct裡面維護了兩套signal_pending, 一套是線程組共享的, 一套是線程獨有的. 通過kill發送的信号被放線上程組共享的signal_pending中, 可以由任意一個線程來處理; 通過pthread_kill發送的信号(pthread_kill是pthread庫的接口, 對應的系統調用中tkill)被放線上程獨有的signal_pending中, 隻能由本線程來處理. 當線程停止/繼續, 或者是收到一個緻命信号時, 核心會将處理動作施加到整個線程組中. NGPT 上面提到的兩種線程庫使用的都是核心級線程(每個線程都對應核心中的一個排程實體), 這種模型稱為1:1模型(1個線程對應1個核心級線程); 而NGPT則打算實作M:N模型(M個線程對應N個核心級線程), 也就是說若幹個線程可能是在同一個執行實體上實作的. 線程庫需要在一個核心提供的執行實體上抽象出若幹個執行實體, 并實作它們之間的排程. 這樣被抽象出來的執行實體稱為使用者級線程. 大體上, 這可以通過為每個使用者級線程配置設定一個棧, 然後通過longjmp的方式進行上下文切換. (百度一下"setjmp/longjmp", 你就知道.) 但是實際上要處理的細節問題非常之多. 目前的NGPT好像并沒有實作所有預期的功能, 并且暫時也不準備去實作. 使用者級線程的切換顯然要比核心級線程的切換快一些, 前者可能隻是一個簡單的長跳轉, 而後者則需要儲存/裝載寄存器, 進入然後退出核心态. (程序切換則還需要切換位址空間等.) 而使用者級線程則不能享受多處理器, 因為多個使用者級線程對應到一個核心級線程上, 一個核心級線程在同一時刻隻能運作在一個處理器上. 不過, M:N的線程模型畢竟提供了這樣一種手段, 可以讓不需要并行執行的線程運作在一個核心級線程對應的若幹個使用者級線程上, 可以節省它們的切換開銷.據說一些類UNIX系統(如Solaris)已經實作了比較成熟的M:N線程模型, 其性能比起linux的線程還是有着一定的優勢.

來源：http://www.360doc.com/content/15/0310/20/7377734_454131481.shtml#