360建设网站免费,公司培训,wordpress中的template,制作公司网站需要几个数据表這幾天由於工作需要#xff0c;琢磨了一下Linux下的多線程的相關資料。Linux下最常用的多線程支持庫為Pthread庫#xff0c;它是glibc庫的組成部分。但是關於Pthread的說明文檔非常缺乏#xff0c;特別是對POSIX多線程規范的介紹以及pthread庫中多線程實現方式的介紹實在是少…這幾天由於工作需要琢磨了一下Linux下的多線程的相關資料。Linux下最常用的多線程支持庫為Pthread庫它是glibc庫的組成部分。但是關於Pthread的說明文檔非常缺乏特別是對POSIX多線程規范的介紹以及pthread庫中多線程實現方式的介紹實在是少之又少。而多線程編程對於系統程序員而言是必須掌握的技術因此總是讓學習中的程序員覺得頭痛不以。我自己也沒有太多多線程編程的經驗在這裡只是把自己收集到的一些關於Linux上多線程還算新的資料進行匯總來拋磚引玉以便相互學習交流。這裡順便提一下市面上有的一本介紹多線程的書《Posix 多線程編程》它是英文版《Programming with POSIX Muiltthread》中譯本這也是半年前我所能找到的唯一專題介紹多線程編程的書。我個人感覺這本書的前面1/3之一的內容寫的還是不錯的但是後面的東西就非常晦澀並且有很多明顯的文字錯誤。看看這本書的翻譯者是好幾個人估計每個人的翻譯能力不同造成了這本書的虎頭蛇尾。 因此我不建議大家去買這本書作為聖經收藏。這本書前半步的內容主要圍繞Posix的多線程介紹的比較精彩的就是幾個多線程編程模型把多線程的互斥和同步機制介紹的挺酣暢的推薦一看。 這些內容並非這本書首創早在《UNIX網絡編程》第二卷進程間通信就有了這些經典的介紹但是能系統的把這些機制結合到多線程編程中來還是有可圈可點之處的。此外畢竟《UNIX網絡編程》兩卷內容太老書也太厚了並不是大多數程序員所能坐下來細細看的。這裡我還想表達一下對微軟在技術上的不足斥責。在msdn中platform sdk部分中的windows多線程編程的內容真是簡陋的可笑只有傻兮兮的建立和退出線程的函數關於互斥條件的介紹一概全無。只能在它的sample代碼中自己去找sample代碼裡面的線程同步方式居然是做一個死循環來死等也不知道它把windows賣這麼多錢是干什麼吃的。 MFC中多線程的封裝倒是看上去像那麼一回事情了但是我想象不出在如此簡陋的系統api上微軟到底是如何實現出MFC上線程功能的。擁護windows的人不要在這裡砸雞蛋最好也能寫一篇windows上的多線程介紹除了。這比砸雞蛋來得有意義多了。 好了書歸正傳繼續說Linux上的多線程。在Linux上從內核角度而言基本沒有什麼線程和進程的區別大家都是進程。一個進程的多個線程只是多個特殊的進程他們雖然有各自的進程描述結構卻共享了同一個代碼上下文。在Linux上這樣的進程稱為輕量級進程Light weight process。致此就是關於線程的總體概念了我們往往就在了解這個概念的情況下開始我們的多線程編程之旅。這對於多線程編程入門已經足夠了然而事實上線程卻要復雜的多。 首先多線程間的優先級調度內存資源(棧)分配和信號投遞就不是簡單的共享同一個進程代碼上下文所能所能解決的。其次效率的問題如何有效的使用多cpu資源(2.4內核的多線程就無法使用多個cpu一個進程的線程都被限制在同一個cpu上運行)。因此多線程庫Pthread的實現並不是一件簡單的事情它建立在特有的線程模型之上。在Linux 2.4內核中 Linux內核中使用了一個內核線程來處理用戶態進程中的多個線程的上下文切換(線程切換)。由於內核中並沒有什麼線程組的概念即一個進程的多個線程因此必須依靠在pthread庫中實現一個額外的線程來管理其他用戶線程(即用戶程序生成的線程)的建立退出資源分配和回收以及線程的切換。由於當時硬件並沒有線程寄存器之類的冬冬來支持多線程因此線程的切換性能和低下並且需要引入復雜的機制在進程的棧中為各個線程劃分出各自的棧數據所在位置並且在切換時進行棧數據拷貝。而最大的問題是內核中缺乏對線程間的同步機制的支持因此pthread庫不得不在底層依靠信號方式來實現同步因此線程互斥中的互斥量操作和條件量操作都轉換為進程的信號操作。pthread的實現中充斥了極其復雜的信號操作。大家都知道信號本身是低速的通信方式因此勢必拖慢了線程的實際性能。最後的問題就是信號處理還有由於內核對線程的無知必須由管理線程來接收信號後投遞給相應的線程一方面是效率低另外一方面由於信號產生的不確定性(比如讀取一個文件的時候突然出錯了)要准確投遞所有的信號給正確的線程難以保證。而在IA-32硬件結構中出現了對線程寄存器的支持因此Pthread的線程上下文切換速度有了很大提高。但是由於硬件限制局限線程的數量必須小於8192個,反正我是覺得已經很多了。於是從2.5代碼開始Linux內核采用了NPTLNative Posix Thread Library)方式。NPTL的設計思想初稿可參考nptl-design.pdf(http://people.redhat.com/drepper/nptl-design.pdf)首先在IA-32和x86-64位體系結構上能實現任意數量的線程數量。通過引入了TLS系統調用可以建立多個GDT全局描述符表每個cpu維護一個描述符表每個表項存放一個線程。其次clone系統調用優化了線程的建立和結束功能。也不再需要額外的調度線程的幫助就可以回收線程資源了。其三信號投遞由內核完成而不再需要額外的用戶態管理線程的幫助而嚴重錯誤信號之間結束整個進程。其四引入了新的退出系統調用exit_group()。原來的exit保留用於退出單個線程exit_group用於退出整個進程。其五 新的exec調用會先結束到一個進程中的所有線程後再載入新程序的執行而不是只結束調用的線程。其六所有線程的資源使用情況(cpu資源內存資源)會報告給整個進程而不再是只報告給初始化線程其七proc文件系統中只顯示初始化線程的信息而不再是所有線程的信息(上萬個線程會把proc文件系統拖死)其八 支持線程脫離 執行Pthread_join的線程不需要再執行no wait。其九由內核來維護初始化線程(變成內核線程了)並在proc文件系統中顯示其狀態並維護直到所有線程退出來保證信號的投遞。其十內核支持無限制的線程數量。最後允許pthread_join在子線程已死之後返回即pthread_join的返回和子線程狀態變成異步的了提高了性能。根據報告NPTL中線程的啟動和中止時間消耗只有Linuxthread的大約1/8當線程數量急遽增加的時候消耗時間的差異更加明顯。在線程間同步試驗中頻繁進出臨界區的時間消耗只有原來的一半。更多的用戶測試報告可以看 http://kerneltrap.org/node/422至於如何在開發中使用NPTL可參考Migrating to Linux kernel 2.6 -- Part 5: Migrating apps to the 2.6 kernel and NPTL(http://linuxdevices.com/articles/AT6753699732.html)。需要做的事情有這麼幾件。1使用2.6的內核的系統平台2確定你的gcc支持NPTL用# getconf GNU_LIBPTHREAD_VERSION命令來查看gcc的編譯時的對多線程的支持方式如果返回的是linuxthreads-0.10說明你的gcc不支持NPTL如果返回的是nptl-0.60這樣的信息說明你的gcc能用來編譯新的NPTL3重新在這樣的系統環境中編譯你的程序不需要改變程序中對pthread的調用(但是某些函數被取消了)
