青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品

sherrylso

C++博客 首頁 新隨筆 聯(lián)系 聚合 管理
  18 Posts :: 0 Stories :: 124 Comments :: 0 Trackbacks

摘要:
        在對多線程并發(fā)的編程環(huán)境下,死鎖是我們經(jīng)常碰到的和經(jīng)常需要解決的問題。所謂死鎖,即:由于資源占用是互斥的,當某個線(進)程提出申請資源后,使得有關進程在無外力協(xié)助下,永遠分配不到必需的資源而無法繼續(xù)運行,這就產生了一種特殊現(xiàn)象死鎖,如下圖:

        線程#1在獲得Lock A后,需要獲得Lock B,而同時,線程#2在Lock B后,需要獲得Lock A。對于線程#1和#2,由于都不能獲得滿足的條件,而無法繼續(xù)執(zhí)行,死鎖就形成了。
        死鎖是多線程并發(fā)編程的大難題,我們可以通過Log Trace、多線程編程輔助工具、IDE調試環(huán)境等手段進行調試、跟蹤。然而,另一個更難對付的問題是“假死鎖”(我在這里暫且稱為“假死鎖”,實在找不到什么更好的稱呼)。所謂的假死鎖,我給出的定義是:在有限的時間內的死鎖。與死鎖不同的是,其持續(xù)的時間是有限的,而大家都知道,死鎖持續(xù)的時間是無限的,如果碰到死鎖,程序接下來是什么都干不了了。而正是由于假死鎖的相對的持續(xù)時間,給我們編程人員會帶來更大的麻煩。可以想象得到,我們想通過某些工具來Trace這樣一個特定的時間段是非常困難的,更多的情況下,我們需要結合LOG進行合理的分析,使得問題得以解決。本文就假死鎖產生的條件,環(huán)境,以及解決的辦法做一個討論。
一、假死鎖的產生條件。

    考慮下面的例子(我只是給給出了偽代碼),假設我們系統(tǒng)中的線程個數(shù)是確定的,有限的。在本例中,系統(tǒng)總的線程數(shù)目是3。如下圖:

線程#1,#2,#3都可能被調度進入臨界區(qū)A,我們假設線程#1執(zhí)行臨界區(qū)A時花費了10s的時間,而在這10s的時間里,線程#2與線程#3都處于等待的狀態(tài)。也就是說:在這個10s的時間里,系統(tǒng)是沒法響應任何的其他請求。我們稱之為10s的假死鎖。如果在這段時間里,系統(tǒng)需要一些關鍵的請求被執(zhí)行,這些關鍵請求是需要real time地被處理,比如說是Timer事件,則后果是不堪設想的。(注意:我們的假定是系統(tǒng)中的線程只有#1,#2,#3)。
       以此,總結一下發(fā)生假死鎖的條件,如下:
--〉臨界區(qū)的代碼在集中的時間段內,可能被系統(tǒng)中的任意線程執(zhí)行,完全由操作系統(tǒng)決定。
--〉臨界區(qū)的代碼在某些情況下,可能是很耗時的。(比如:其執(zhí)行時間大于100ms,或者,甚至是秒級別的)
二、在Proactor(IOCP)中的假死鎖。
        在前面的文章中,我提到過在windows平臺上,Proactor設計模式是基于IOCP的。在這里,本文不會用過多的語言來闡述Proactor是怎樣的設計,重點放在Proactor的假死鎖及其一些解決的辦法。另外需要說明的是,我這里所說的Proactor,在技術層面上,等同于IOCP,我們也可以按照IOCP來理解我所闡釋的概念。
        我們都知道,IOCP是靠工作者線程來驅動的。工作者線程與一個完成端口對象相關聯(lián),當IO 請求被投遞到完成端口對象時,這些線程為完成端口服務。需要說明的是,應該創(chuàng)建多少個線程來為完成端口服務,是你的應用設計來決定的(很重要的的一點是:在調用CreateIoCompletionPort時指定的并發(fā)線程的個數(shù),和創(chuàng)建的工作者線程的個數(shù)是有區(qū)別的,詳細的技術細節(jié),請參考其他資料)。但是總的來說,在你的系統(tǒng)交付運行后,工作者線程的線程數(shù)目是一個確定的值。其結構圖,大致如下:

         我們假定使用了線程數(shù)目為4的工作者線程來為完成端口服務,它們通過調用來GetQueuedCompletionStatus方法來從完成端口中獲取IO相關的packet,一旦獲得,它們都會回調業(yè)務邏輯層的代碼來進行相關的業(yè)務邏輯處理。到這里我們看到,假設,在業(yè)務邏輯層存在臨界互斥區(qū),并且在某一個集中的時間段內,工作者線程都可能被調度執(zhí)行該臨界互斥區(qū),那么,假死鎖的條件基本形成,如果某一個線程在該區(qū)域花費的時間比較長,假死鎖就會發(fā)生。
        一般來說,解決這樣的問題的關鍵就是打破形成假死鎖的條件:
       第一、在回調函數(shù)里,盡量減少鎖的使用。
       第二、減量減少臨界互斥區(qū)的執(zhí)行時間。對于一些慢速的操作尤其注意。比如:當你在臨界互斥區(qū)訪問慢速的IO操作時(打開文件,讀寫文件等),可能需要考慮Cache機制,通過使用內存來代替慢速的disk。
       第三、將臨界互斥區(qū)代碼委托給另外獨立的線程(或線程組)執(zhí)行,代價是增加這些線程間的通訊。
       第四、通過使用流控等手段,避免讓所有的線程在集中的時間段內訪問該臨界互斥區(qū)。
三、結束語:

         事實上,類似這樣的問題,一旦存在,是很難發(fā)現(xiàn)和調試的。不過對于多線程的編程,我們都應該遵守以下的基本原則,以最大化的防止死鎖和假死鎖的發(fā)生。

         --> 盡量減少鎖的使用頻率和保護范圍。
         --> 當線程在互斥鎖的保護范圍內執(zhí)行代碼時,應該:盡量減少對慢速IO設備的訪問(如:disk),盡量避免獲得其它互斥資源。
         --〉正確使用各種鎖,包括:原子操作原語,Read Lock, Write Lock, 和Recursive Lock等。這些鎖在不同的場景下有著不同的作用。
posted on 2007-08-12 15:41 愛上龍卷風 閱讀(4121) 評論(9)  編輯 收藏 引用

Feedback

# re: 線程互斥執(zhí)行之假死鎖現(xiàn)象 2007-08-12 20:30 若弱
你所說的其實叫做“活鎖”是資源緊俏造成的,另外,其實完全可以用lock-free來代理鎖機制的。這樣就可以不會死鎖了
  回復  更多評論
  

# re: 線程互斥執(zhí)行之假死鎖現(xiàn)象 2007-08-13 13:26 阿福
為了吸引眼球,創(chuàng)建一個新名詞…………拜托,一點學術精神都沒有!  回復  更多評論
  

# re: 線程互斥執(zhí)行之假死鎖現(xiàn)象 2007-08-13 15:23 SuperPlayeR
最后的總結第二點,應該說是盡量減少互斥鎖保護范圍內代碼的執(zhí)行時間。減少對慢速IO設備的訪問其實目的只是縮短時間而已。  回復  更多評論
  

# re: 線程互斥執(zhí)行之假死鎖現(xiàn)象 2007-08-13 22:42 愛上龍卷風
@阿福
我確實不知道該把這類現(xiàn)象稱為什么,你有什么好主意,給點建設性的意見!
另外,這里不是在發(fā)表學術文章,只是開發(fā)經(jīng)驗的總結,OK?  回復  更多評論
  

# re: 線程互斥執(zhí)行之假死鎖現(xiàn)象 2007-08-13 22:53 愛上龍卷風
@若弱
直接原因是由于加鎖保護的代碼執(zhí)行時間長造成的。
另外,閣下說的ock-free來代理鎖機制,是什么意思?  回復  更多評論
  

# re: 線程互斥執(zhí)行之假死鎖現(xiàn)象 2007-08-16 10:53 若弱
不好意思,我打錯了一個字,應該是“代替”

其實所謂的lock-free(無鎖)實質上是使用了一個CPU的時鐘周期的鎖,
鎖的時間是要盡可能的短,但是再短也不能完全避免資源不足造成活鎖(或者說較長時間等待)現(xiàn)象。當然是有可能采用wait-free機制的,不過目前的實現(xiàn)代價太大,效率還沒傳統(tǒng)的鎖機制高呢。  回復  更多評論
  

# re: 線程互斥執(zhí)行之假死鎖現(xiàn)象 2007-08-17 15:55 愛上龍卷風
@若弱
謝謝你的comments。
至于你提到的livelock的概念,我在網(wǎng)上查了些資料,基本上有兩種定義:
1)livelock-An endless loop in program execution. It occurs when a process repeats itself, because it continues to receive erroneous information. It can also occur when a process that calls another process is itself called by that process, and there is no logic to detect this situation and stop the operation. A livelock differs from a "deadlock," in that processing continues to take place, rather than just waiting in an idle loop(From answers).
2)活鎖-如果事務T1封鎖了數(shù)據(jù)R,事務T2又請求封鎖R,于是T2等待。T3也請求封鎖R,當T1釋放了R上的封鎖之后系統(tǒng)首先批準了T3的請求,T2仍然等待。然后T4又請求封鎖R,當T3釋放了R上的封鎖之后系統(tǒng)又批準了T4的請求,...,T2有可能永遠等待,這就是活鎖的情形(來自數(shù)據(jù)庫領域)
對于這兩種定義,我個人偏向于第一個定義:即程序進入無止的循環(huán)當中,無法結束。
不過無論哪種方式,都不適合本文的定義,即:既定時間的內的死鎖。
關于你說的Lock-free機制,一般來說,有兩種方法:
第一、對現(xiàn)有的算法改動,使用新的Lock-free算法。這種方法比較難于實現(xiàn)。
最簡單的莫過于:將臨界互斥區(qū)代碼委托給另外獨立的線程,使同步的操作變成異步(本文已經(jīng)提到過)。
第二、使用原子操作原語,比如windows平臺上的互鎖函數(shù)族,如InterlockedCompareExchange。但是他們不能解決事務的問題。

  回復  更多評論
  

# re: 線程互斥執(zhí)行之假死鎖現(xiàn)象 2007-08-20 10:37 若弱
@愛上龍卷風
關于活鎖,我個人也是傾向于第一種理解,事實上,有這樣一種情況出現(xiàn),系統(tǒng)并沒有死鎖,但是因為資源不足,造成推進速度過慢,系統(tǒng)花太多的時間用于等待足夠的資源出現(xiàn)。就好比是餐館的例子,廚師等幫工清洗好盤子,幫工客人吃完的盤子,而客人不愿意整個桌子空蕩蕩的而不愿意把盤子吃空知道新的菜上來。這種情況在計算機環(huán)境中很容易出現(xiàn),但是絕對不會推進不下去,只是速度非常慢,看起來像死鎖一樣,但是絕對不是死鎖。當然解決這個問題的辦法是增加盤子(資源)的供應量,或者減少資源的占用時間。

  回復  更多評論
  

# re: 線程互斥執(zhí)行之假死鎖現(xiàn)象 2008-01-07 23:14 abettor.org
如果有個類似TryLock之類的方法就好了。  回復  更多評論
  

青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品
  • <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>
            久久婷婷蜜乳一本欲蜜臀| 国产精品嫩草久久久久| 亚洲毛片视频| 亚洲精品美女久久久久| 免费日韩精品中文字幕视频在线| 久久久国产亚洲精品| 美腿丝袜亚洲色图| 亚洲精品久久久久久久久| 亚洲特色特黄| 免费观看日韩av| 国产精品免费电影| 亚洲第一精品福利| 亚洲一区不卡| 久久婷婷麻豆| 亚洲人永久免费| 性做久久久久久| 欧美激情乱人伦| 国产美女精品视频| 日韩午夜电影| 久久久999| aaa亚洲精品一二三区| 久久成人综合视频| 国产精品啊啊啊| 亚洲精品乱码久久久久久| 欧美一区二视频在线免费观看| 欧美大片免费观看在线观看网站推荐| 99精品国产在热久久婷婷| 新67194成人永久网站| 欧美日韩国产成人在线| 精品999久久久| 性欧美长视频| 999亚洲国产精| 免费看黄裸体一级大秀欧美| 国产日韩欧美a| 亚洲午夜羞羞片| 最新日韩av| 老色鬼久久亚洲一区二区| 国产精品伦一区| 在线亚洲欧美专区二区| 嫩草影视亚洲| 欧美在线视频二区| 国产精品入口夜色视频大尺度| 亚洲久久一区二区| 免费的成人av| 久久久久成人精品免费播放动漫| 国产精品videosex极品| 日韩午夜av电影| 亚洲经典视频在线观看| 久久久美女艺术照精彩视频福利播放| 欧美黑人一区二区三区| 亚洲在线成人精品| 欧美亚州在线观看| 这里只有精品丝袜| 亚洲国产一区二区三区青草影视| 久久久精品国产免费观看同学| 国产乱码精品一区二区三区五月婷 | 亚洲视频在线观看| 亚洲激情一区二区| 免费在线欧美黄色| 91久久精品国产91久久性色tv | 亚洲精选久久| 欧美激情亚洲国产| 亚洲美女在线观看| 亚洲国产视频直播| 欧美精品v国产精品v日韩精品| 最新国产成人在线观看| 欧美激情视频给我| 欧美精品日韩精品| 亚洲免费观看| 最新国产成人在线观看| 欧美人成在线| 亚洲影视在线播放| 亚洲一区二区三区中文字幕| 国产精品美女久久久久久久| 欧美亚洲网站| 久久狠狠久久综合桃花| 在线观看欧美精品| 亚洲黄页视频免费观看| 欧美日韩在线看| 欧美资源在线| 免费看黄裸体一级大秀欧美| 一区二区免费在线观看| 亚洲视频福利| 曰本成人黄色| 亚洲精品乱码久久久久久按摩观| 欧美激情综合色综合啪啪| 亚洲素人在线| 欧美一区1区三区3区公司| 亚洲第一伊人| 一级日韩一区在线观看| 国产性做久久久久久| 欧美激情一二三区| 国产精品第一页第二页第三页| 欧美一区国产一区| 美女啪啪无遮挡免费久久网站| 亚洲视频在线观看| 久久xxxx精品视频| 欧美国产日韩精品免费观看| 亚洲一区bb| 老司机精品久久| 亚洲综合国产精品| 卡通动漫国产精品| 午夜伦欧美伦电影理论片| 免费观看国产成人| 午夜精品久久久久久久99黑人| 久久免费国产精品| 亚洲一区二区免费| 久久婷婷成人综合色| 午夜精品在线视频| 欧美国产日韩一区二区三区| 欧美一级淫片aaaaaaa视频| 久久久一二三| 午夜精品亚洲| 欧美另类视频在线| 欧美www在线| 国产一区二区按摩在线观看| 99在线|亚洲一区二区| 亚洲人被黑人高潮完整版| 欧美在线观看一二区| 亚洲中无吗在线| 欧美精品福利在线| 欧美国产国产综合| 激情文学一区| 欧美在线不卡视频| 久久不射中文字幕| 国产精品一区免费观看| 99国产精品国产精品久久| 在线播放中文一区| 久久福利资源站| 久久激情视频免费观看| 国产精品美女主播| 一区二区三区你懂的| 一区二区三区国产在线| 欧美激情在线有限公司| 亚洲国产精品久久久久秋霞影院| 狠狠操狠狠色综合网| 午夜在线视频一区二区区别| 午夜视频久久久| 国产精品一区二区三区四区五区| 亚洲一区二区三区四区在线观看| 亚洲免费网站| 国产精品一区二区三区免费观看| 亚洲已满18点击进入久久| 亚洲女同同性videoxma| 国产精品一区=区| 久久久精品国产一区二区三区 | 最新中文字幕一区二区三区| 亚洲欧洲偷拍精品| 欧美福利精品| 日韩视频不卡中文| 亚洲一区二区精品在线观看| 国产精品黄视频| 午夜精品剧场| 蜜桃av一区| 亚洲精品一区在线| 欧美日韩午夜激情| 一道本一区二区| 欧美专区在线播放| 在线播放一区| 欧美日韩国产一区二区| 中文久久精品| 久久综合九色99| 亚洲精品在线免费观看视频| 欧美人与性动交α欧美精品济南到| 亚洲日本欧美在线| 亚洲一区二区三区在线视频| 国产精品蜜臀在线观看| 久久久99国产精品免费| 亚洲第一区中文99精品| 亚洲天堂成人在线视频| 国内精品久久久久久久影视麻豆| 另类欧美日韩国产在线| 亚洲美女毛片| 久久精品国产v日韩v亚洲| 怡红院av一区二区三区| 欧美日本国产| 久久精品91| 免费日韩av| 亚洲男人第一网站| 国语自产精品视频在线看一大j8 | 国产精品99久久99久久久二8 | 亚洲欧洲一区二区三区| 欧美一区三区二区在线观看| 亚洲二区在线视频| 国产精品女主播在线观看 | 免费成人av在线| 亚洲一区二区av电影| 欧美成人免费在线视频| 午夜日韩av| 亚洲精品日韩在线观看| 国产在线乱码一区二区三区| 欧美日韩dvd在线观看| 久久久久久久久蜜桃| 亚洲天堂偷拍| 日韩网站在线看片你懂的| 欧美国产亚洲视频| 久久婷婷国产麻豆91天堂| 性欧美videos另类喷潮| 亚洲神马久久| 一区二区福利|