• <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>

            sherrylso

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

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

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

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

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

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

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

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

            Feedback

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

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

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

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

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

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

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

            # re: 線程互斥執(zhí)行之假死鎖現(xiàn)象 2007-08-17 15:55 愛上龍卷風(fēng)
            @若弱
            謝謝你的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)活鎖-如果事務(wù)T1封鎖了數(shù)據(jù)R,事務(wù)T2又請(qǐng)求封鎖R,于是T2等待。T3也請(qǐng)求封鎖R,當(dāng)T1釋放了R上的封鎖之后系統(tǒng)首先批準(zhǔn)了T3的請(qǐng)求,T2仍然等待。然后T4又請(qǐng)求封鎖R,當(dāng)T3釋放了R上的封鎖之后系統(tǒng)又批準(zhǔn)了T4的請(qǐng)求,...,T2有可能永遠(yuǎn)等待,這就是活鎖的情形(來自數(shù)據(jù)庫(kù)領(lǐng)域)
            對(duì)于這兩種定義,我個(gè)人偏向于第一個(gè)定義:即程序進(jìn)入無止的循環(huán)當(dāng)中,無法結(jié)束。
            不過無論哪種方式,都不適合本文的定義,即:既定時(shí)間的內(nèi)的死鎖。
            關(guān)于你說的Lock-free機(jī)制,一般來說,有兩種方法:
            第一、對(duì)現(xiàn)有的算法改動(dòng),使用新的Lock-free算法。這種方法比較難于實(shí)現(xiàn)。
            最簡(jiǎn)單的莫過于:將臨界互斥區(qū)代碼委托給另外獨(dú)立的線程,使同步的操作變成異步(本文已經(jīng)提到過)。
            第二、使用原子操作原語,比如windows平臺(tái)上的互鎖函數(shù)族,如InterlockedCompareExchange。但是他們不能解決事務(wù)的問題。

              回復(fù)  更多評(píng)論
              

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

              回復(fù)  更多評(píng)論
              

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


            只有注冊(cè)用戶登錄后才能發(fā)表評(píng)論。
            網(wǎng)站導(dǎo)航: 博客園   IT新聞   BlogJava   博問   Chat2DB   管理


            久久性生大片免费观看性| 精品乱码久久久久久久| 久久久无码精品午夜| 欧美久久亚洲精品| 99久久人妻无码精品系列蜜桃| 久久香蕉国产线看观看乱码| 麻豆久久久9性大片| 精品久久久久久中文字幕| 亚洲?V乱码久久精品蜜桃 | 久久久久久亚洲精品不卡| 欧美激情一区二区久久久| 久久噜噜电影你懂的| 国产亚洲精久久久久久无码77777| 久久亚洲中文字幕精品有坂深雪| 国产精品99久久久久久猫咪 | 久久天天躁狠狠躁夜夜2020一| 午夜不卡久久精品无码免费| 久久精品成人免费国产片小草| 久久国产欧美日韩精品| 久久亚洲国产精品成人AV秋霞| 久久99精品综合国产首页| 人人狠狠综合久久88成人| 亚洲国产香蕉人人爽成AV片久久 | 午夜精品久久久久成人| 99久久99久久精品免费看蜜桃| 99久久夜色精品国产网站| 开心久久婷婷综合中文字幕| 人人狠狠综合久久亚洲88| 久久精品无码午夜福利理论片 | 99久久精品国产一区二区 | 久久精品国产半推半就| 久久精品aⅴ无码中文字字幕重口| 国产69精品久久久久久人妻精品| 欧美精品一区二区久久 | 久久午夜羞羞影院免费观看| 欧美日韩成人精品久久久免费看| 久久99热这里只有精品国产| 国产一区二区精品久久岳| 99久久精品国产一区二区| 久久精品成人影院| 久久只有这里有精品4|