• <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>
            posts - 200, comments - 8, trackbacks - 0, articles - 0
            轉發請注明出處:http://m.shnenglu.com/mysileng/admin/EditPosts.aspx?postid=196971
                剛寫了程序發現點問題。假設一個程序有多個線程,有一個全局互斥鎖M....在某線程A獲得鎖以后,這個時候來了一個信號(假設這個信號注冊了自己的處理程序),那么需要進入信號處理程序,進入以后信號處理處理程序也要獲得這個鎖。問題來了?會死鎖么?
                我們知道同一線程如果重復申請同一個互斥鎖那么必然會死鎖?這里問題轉換到信號處理函數跟之前的線程A會是同一個線程上下文么(即是同一個線程么)?我們試驗一下。實驗之前需要明確幾點:
                1.根據APUE 12.8,進程的處理函數與處理方式是進程中所有線程共享的。
                2.根據APUE 12.8,如果進程接收到信號,該信號只會被遞送到某一個單獨線程。一般情況下由那個線程引起信號則遞送到那個線程。如果沒有線程引發信號,信號被發送到任意線程。



                 上面程序首先共享了一個共同的SIGUSR1信號處理函數,主控線程A然后產生一個線程B,線程B首先獲得全局互斥鎖,然后運行一個長5秒的程序,然后釋放鎖。在B運行了大概2秒的時候,線程A給本進程(注意是進程,而不是某線程)發送一個SIGUSR1信號。此時,會死鎖么?編譯運行看結果.

                連續運行了5次,都沒有死鎖。我們分析一下,當進程接收信號時,進程把信號并沒有遞送給線程B(因為沒有產生死鎖),也就是說是不是這個遞送過程被優化了?還是我們真的運氣好?需要進一步探查。接下來我們指定把信號遞送給線程B,看會不會死鎖。

                接下來編譯運行:

                不出意料,果然死鎖了。
                也就是說,關于線程與信號處理函數獲得同一把互斥鎖的問題,關鍵是看信號被遞送給了那個線程,如果信號是被遞送給了獲得鎖的那個線程,就會死鎖,如果不是之前獲得鎖的線程,程序就繼續運行。
            一本久久综合亚洲鲁鲁五月天亚洲欧美一区二区 | 精品国产乱码久久久久久人妻| 99久久做夜夜爱天天做精品| 精品人妻伦九区久久AAA片69| 乱亲女H秽乱长久久久| 久久久黄片| 久久精品一本到99热免费| 国产成人综合久久精品尤物| 久久亚洲AV成人无码软件| 热99re久久国超精品首页| 婷婷伊人久久大香线蕉AV| 久久精品中文字幕第23页| 午夜久久久久久禁播电影| 性高朝久久久久久久久久| 久久精品无码一区二区三区| 久久99久久99精品免视看动漫 | 久久精品国产只有精品66| 无码AV中文字幕久久专区| 久久婷婷人人澡人人爽人人爱| 午夜不卡888久久| 国产一级做a爰片久久毛片| 一本一本久久A久久综合精品| 亚洲国产成人精品久久久国产成人一区二区三区综 | 久久精品草草草| 久久亚洲精精品中文字幕| 久久精品国产清自在天天线 | 精品伊人久久大线蕉色首页| 四虎亚洲国产成人久久精品| 久久精品国产精品亚洲| 夜夜亚洲天天久久| 日本道色综合久久影院| 久久久精品免费国产四虎| 国产精品久久久久9999高清| 久久99精品久久久久久动态图 | 久久精品这里只有精99品| 久久无码AV中文出轨人妻| 久久久久久青草大香综合精品| 国产叼嘿久久精品久久| 欧美粉嫩小泬久久久久久久 | 午夜精品久久久久久99热| 日韩精品久久久久久免费|