<meter id="pryje"><nav id="pryje"><delect id="pryje"></delect></nav></meter>
          <label id="pryje"></label>

          新聞中心

          EEPW首頁 > 嵌入式系統(tǒng) > 設(shè)計(jì)應(yīng)用 > Linux多線程編程和Linux 2.6下的NPTL

          Linux多線程編程和Linux 2.6下的NPTL

          作者: 時(shí)間:2012-05-31 來源:網(wǎng)絡(luò) 收藏

          這幾天由于工作需要,琢磨了一下下的多的相關(guān)資料。下最常用的多支持庫為 Pthread庫,它是glibc庫的組成部分。但是關(guān)于Pthread的說明文檔非常缺乏,特別是對(duì)POSIX多規(guī)范的介紹以及pthread庫中多線程實(shí)現(xiàn)方式的介紹實(shí)在是少之又少。而多線程對(duì)于系統(tǒng)程序員而言是必須掌握的技術(shù),因此總是讓學(xué)習(xí)中的程序員覺得頭痛不以。我自己也沒有太多多線程的經(jīng)驗(yàn),在這里只是把自己收集到的一些關(guān)于上多線程還算新的資料進(jìn)行匯總來拋磚引玉,以便相互學(xué)習(xí)交流。

          本文引用地址:http://www.ex-cimer.com/article/148957.htm

          這里順便提一下市面上有的一本介紹多線程的書《Posix 多線程》,它是英文版《Programming with POSIX Muiltthread》中譯本,這也是半年前我所能找到的唯一專題介紹多線程編程的書。我個(gè)人感覺這本書的前面1/3之一的內(nèi)容寫的還是不錯(cuò)的,但是后面的東西就非?;逎⑶矣泻芏嗝黠@的文字錯(cuò)誤??纯催@本書的翻譯者是好幾個(gè)人,估計(jì)每個(gè)人的翻譯能力不同造成了這本書的虎頭蛇尾。因此我不建議大家去買這本書作為圣經(jīng)收藏。這本書前半步的內(nèi)容主要圍繞Posix的多線程,介紹的比較精彩的就是幾個(gè)多線程編程模型,把多線程的互斥和同步機(jī)制介紹的挺酣暢的,推薦一看。這些內(nèi)容并非這本書首創(chuàng),早在《UNIX網(wǎng)絡(luò)編程》第二卷進(jìn)程間通信就有了這些經(jīng)典的介紹,但是能系統(tǒng)的把這些機(jī)制結(jié)合到多線程編程中來還是有可圈可點(diǎn)之處的。此外畢竟《UNIX網(wǎng)絡(luò)編程》兩卷內(nèi)容太老,書也太厚了,并不是大多數(shù)程序員所能坐下來細(xì)細(xì)看的。這里我還想表達(dá)一下對(duì)微軟在技術(shù)上的不足斥責(zé)。在 msdn中platform sdk部分中的windows多線程編程的內(nèi)容真是簡(jiǎn)陋的可笑,只有傻兮兮的建立和退出線程的函數(shù),關(guān)于互斥,條件的介紹一概全無。只能在它的 sample代碼中自己去找,sample代碼里面的線程同步方式居然是做一個(gè)死循環(huán)來死等,也不知道它把windows賣這么多錢是干什么吃的。 MFC中多線程的封裝倒是看上去像那么一回事情了,但是我想象不出在如此簡(jiǎn)陋的系統(tǒng)api上微軟到底是如何實(shí)現(xiàn)出MFC上線程功能的。擁護(hù)windows 的人不要在這里砸雞蛋,最好也能寫一篇windows上的多線程介紹除了。這比砸雞蛋來得有意義多了。 好了,書歸正傳繼續(xù)說Linux上的多線程。

          在Linux 上,從內(nèi)核角度而言,基本沒有什么線程和進(jìn)程的區(qū)別--大家都是進(jìn)程。一個(gè)進(jìn)程的多個(gè)線程只是多個(gè)特殊的進(jìn)程他們雖然有各自的進(jìn)程描述結(jié)構(gòu),卻共享了同一個(gè)代碼上下文。在Linux上,這樣的進(jìn)程稱為輕量級(jí)進(jìn)程Light weight process。致此,就是關(guān)于線程的總體概念了,我們往往就在了解這個(gè)概念的情況下開始我們的多線程編程之旅。這對(duì)于多線程編程入門已經(jīng)足夠了,然而事實(shí)上線程卻要復(fù)雜的多。首先多線程間的優(yōu)先級(jí)調(diào)度,內(nèi)存資源(棧)分配和信號(hào)投遞就不是簡(jiǎn)單的共享同一個(gè)進(jìn)程代碼上下文所能所能解決的。其次,效率的問題:如何有效的使用多 cpu資源(2.4內(nèi)核的多線程就無法使用多個(gè)cpu,一個(gè)進(jìn)程的線程都被限制在同一個(gè)cpu上運(yùn)行)。因此多線程庫Pthread的實(shí)現(xiàn)并不是一件簡(jiǎn)單的事情,它建立在特有的線程模型之上。

          在Linux 2.4內(nèi)核中, Linux內(nèi)核中使用了一個(gè)內(nèi)核線程來處理用戶態(tài)進(jìn)程中的多個(gè)線程的上下文切換(線程切換)。由于內(nèi)核中并沒有什么線程組的概念,即一個(gè)進(jìn)程的多個(gè)線程,因此必須依靠在pthread庫中實(shí)現(xiàn)一個(gè)額外的線程來管理其他用戶線程(即用戶程序生成的線程)的建立,退出,資源分配和回收以及線程的切換。由于當(dāng)時(shí)硬件并沒有線程寄存器之類的冬冬來支持多線程,因此線程的切換性能和低下,并且需要引入復(fù)雜的機(jī)制在進(jìn)程的棧中為各個(gè)線程劃分出各自的棧數(shù)據(jù)所在位置,并且在切換時(shí)進(jìn)行棧數(shù)據(jù)拷貝。而最大的問題是內(nèi)核中缺乏對(duì)線程間的同步機(jī)制的支持,因此pthread庫不得不在底層依靠信號(hào)方式來實(shí)現(xiàn)同步,因此線程互斥中的互斥量操作和條件量操作都轉(zhuǎn)換為進(jìn)程的信號(hào)操作。pthread的實(shí)現(xiàn)中充斥了極其復(fù)雜的信號(hào)操作。大家都知道信號(hào)本身是低速的通信方式,因此勢(shì)必拖慢了線程的實(shí)際性能。最后的問題就是信號(hào)處理,還有由于內(nèi)核對(duì)線程的無知,必須由管理線程來接收信號(hào)后投遞給相應(yīng)的線程,一方面是效率低,另外一方面由于信號(hào)產(chǎn)生的不確定性(比如讀取一個(gè)文件的時(shí)候突然出錯(cuò)了),要準(zhǔn)確投遞所有的信號(hào)給正確的線程難以保證。

          而在IA-32硬件結(jié)構(gòu)中,出現(xiàn)了對(duì)線程寄存器的支持,因此Pthread的線程上下文切換速度有了很大提高。但是由于硬件限制局限,線程的數(shù)量必須小于8192個(gè),反正我是覺得已經(jīng)很多了。

          于是從2.5代碼開始Linux內(nèi)核采用了Native Posix Thread Library)方式。的設(shè)計(jì)思想初稿可參考nptl-design.pdf(http://people.redhat.com/drepper/nptl-design.pdf)

          首先在IA-32和x86-64位體系結(jié)構(gòu)上能實(shí)現(xiàn)任意數(shù)量的線程數(shù)量。通過引入了TLS系統(tǒng)調(diào)用可以建立多個(gè)GDT全局描述符表,每個(gè)cpu維護(hù)一個(gè)描述符表,每個(gè)表項(xiàng)存放一個(gè)線程。

          其次,clone系統(tǒng)調(diào)用優(yōu)化了線程的建立和結(jié)束功能。也不再需要額外的調(diào)度線程的幫助就可以回收線程資源了。

          其三,信號(hào)投遞由內(nèi)核完成,而不再需要額外的用戶態(tài)管理線程的幫助,而嚴(yán)重錯(cuò)誤信號(hào)之間結(jié)束整個(gè)進(jìn)程。

          其四,引入了新的退出系統(tǒng)調(diào)用exit_group()。原來的exit保留用于退出單個(gè)線程,exit_group用于退出整個(gè)進(jìn)程。

          其五, 新的exec調(diào)用會(huì)先結(jié)束到一個(gè)進(jìn)程中的所有線程后再載入新程序的執(zhí)行,而不是只結(jié)束調(diào)用的線程。

          其六,所有線程的資源使用情況(cpu資源,內(nèi)存資源)會(huì)報(bào)告給整個(gè)進(jìn)程,而不再是只報(bào)告給初始化線程

          其七,proc文件系統(tǒng)中只顯示初始化線程的信息,而不再是所有線程的信息(上萬個(gè)線程會(huì)把proc文件系統(tǒng)拖死)

          其八, 支持線程脫離, 執(zhí)行Pthread_join的線程不需要再執(zhí)行no wait。

          其九,由內(nèi)核來維護(hù)初始化線程(變成內(nèi)核線程了),并在proc文件系統(tǒng)中顯示其狀態(tài),并維護(hù)直到所有線程退出來保證信號(hào)的投遞。

          其十,內(nèi)核支持無限制的線程數(shù)量。

          最后,允許pthread_join在子線程已死之后返回,即pthread_join的返回和子線程狀態(tài)變成異步的了,提高了性能。

          根據(jù)報(bào)告,中線程的啟動(dòng)和中止時(shí)間消耗只有Linuxthread的大約1/8,當(dāng)線程數(shù)量急遽增加的時(shí)候,消耗時(shí)間的差異更加明顯。

          在線程間同步試驗(yàn)中,頻繁進(jìn)出臨界區(qū)的時(shí)間消耗只有原來的一半。

          更多的用戶測(cè)試報(bào)告可以看 http://kerneltrap.org/node/422

          至于如何在開發(fā)中使用NPTL可參考Migrating to Linux kernel -- Part 5: Migrating apps to the kernel and NPTL(http://linuxdevices.com/articles/AT6753699732.html)。需要做的事情有這么幾件。

          1:使用的內(nèi)核的系統(tǒng)平臺(tái)

          2:確定你的gcc支持NPTL

          用# getconf GNU_LIBPTHREAD_VERSION命令來查看gcc的編譯時(shí)的對(duì)多線程的支持方式

          如果返回的是linuxthreads-0.10,說明你的gcc不支持NPTL

          如果返回的是nptl-0.60這樣的信息,說明你的gcc能用來編譯新的NPTL

          3:重新在這樣的系統(tǒng)環(huán)境中編譯你的程序,不需要改變程序中對(duì)pthread的調(diào)用(但是某些函數(shù)被取消了)

          linux操作系統(tǒng)文章專題:linux操作系統(tǒng)詳解(linux不再難懂)


          關(guān)鍵詞: Linux NPTL 2.6 編程 線程

          評(píng)論


          相關(guān)推薦

          技術(shù)專區(qū)

          關(guān)閉
          看屁屁www成人影院,亚洲人妻成人图片,亚洲精品成人午夜在线,日韩在线 欧美成人 (function(){ var bp = document.createElement('script'); var curProtocol = window.location.protocol.split(':')[0]; if (curProtocol === 'https') { bp.src = 'https://zz.bdstatic.com/linksubmit/push.js'; } else { bp.src = 'http://push.zhanzhang.baidu.com/push.js'; } var s = document.getElementsByTagName("script")[0]; s.parentNode.insertBefore(bp, s); })();