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

            Error

            C++博客 首頁 新隨筆 聯系 聚合 管理
              217 Posts :: 61 Stories :: 32 Comments :: 0 Trackbacks
             

            網上很容易找到一個用boost::shared_mutex來作為讀寫鎖的例子:

            1. typedef boost::shared_mutex rwmutex;  
            2. typedef boost::shared_lock<rwmutex> readLock;  
            3. typedef boost::unique_lock<rwmutex> writeLock;   

             

            一直沒有懷疑過這個做法,直到最近項目中出現一個死鎖問題,查了很久才發現是上面這種寫法造成的。

            寫測試代碼還原死鎖的情景如下:

            1. #include <boost/thread/shared_mutex.hpp>   
            2. #include <boost/thread/shared_lock_guard.hpp>   
            3. #include <boost/thread.hpp>   
            4. #include <iostream>   
            5. #include <Windows.h>   
            6. using namespace std;  
            7. typedef boost::shared_mutex rwmutex;  
            8. typedef boost::shared_lock<rwmutex> readLock;  
            9. typedef boost::unique_lock<rwmutex> writeLock;  
            10.   
            11. rwmutex m_mutex;  
            12. void func1()  
            13. {  
            14.     writeLock lock1(m_mutex);  
            15.     cout << "fffffffffffffff" << endl;  
            16. }  
            17.   
            18. int main()  
            19. {  
            20.     {  
            21.         boost::thread tt(func1);  
            22.         readLock lock(m_mutex); // 加讀鎖   
            23.         {  
            24.             Sleep(3000);  // 故意睡眠3秒將線程切換出去   
            25.             readLock lock(m_mutex); // 醒來后再次加讀鎖   
            26.             cout << "rrrrrrrrrrrrrrrrrr" << endl;  
            27.         }  
            28.     }  
            29. }  

            情形描述如下:

            1:主線程先給m_mutex加讀鎖。

            2:主線程故意睡眠3秒將執行權限切換出去。

            3:func1線程獲得執行機會,嘗試加寫鎖被掛起。因為主線程已經有一個讀鎖占用,寫鎖必須等待這個讀鎖釋放才能進入。

            4:主線程睡眠3秒醒來,后續代碼想獲取一個讀鎖。由于這個時候已經有一個寫鎖在等待進入,那么這個讀鎖排隊在寫鎖后面,同樣被掛起。

            5:主線程和func1線程都被掛起了,發生死鎖。

            上面的測試代碼,如果中間沒有sleep(3000),出現死鎖的概率很低,但總歸是存在死鎖的可能。

             

            總結:

            以前一直認為readLock鎖和遞歸鎖一樣,在同一個線程多次進入沒有關系才會造成上面的死鎖出現。所以,boost::shared_lock使用要小心,千萬不要同一個線程多次進入。

            posted on 2013-01-31 18:46 Enic 閱讀(1571) 評論(0)  編輯 收藏 引用 所屬分類: about boost
            久久精品人成免费| 人妻无码精品久久亚瑟影视| 久久精品无码专区免费东京热| 乱亲女H秽乱长久久久| 91久久精品无码一区二区毛片| 国产女人aaa级久久久级| 伊人热热久久原色播放www| 亚洲AV无码久久精品蜜桃| 91精品国产9l久久久久| 国产精品日韩深夜福利久久| 久久免费看黄a级毛片| 一级做a爰片久久毛片16| 亚洲国产精品久久久天堂| 国产情侣久久久久aⅴ免费| 亚洲人成无码网站久久99热国产| 久久er99热精品一区二区| 国内精品伊人久久久久妇| 国产AV影片久久久久久| 日产精品99久久久久久| 伊人久久大香线蕉综合热线| 久久精品国产秦先生| 无码任你躁久久久久久老妇App| 99久久婷婷国产综合精品草原 | 久久福利资源国产精品999| 精品久久久久久亚洲| 久久精品人人做人人爽97| 精品久久久久成人码免费动漫| 精品久久久久久无码国产| 一级做a爰片久久毛片人呢| 国产成人无码久久久精品一| 久久精品国产亚洲av水果派 | 亚洲女久久久噜噜噜熟女| 久久久久噜噜噜亚洲熟女综合| 91秦先生久久久久久久| 久久国产精品一区二区| 久久精品男人影院| 亚洲国产精品婷婷久久| 久久久久免费精品国产| 精品久久久久久国产三级| 久久精品国产99国产精品| 日本加勒比久久精品|