• <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 閱讀(1565) 評論(0)  編輯 收藏 引用 所屬分類: about boost
            国产精品久久自在自线观看| 中文成人无码精品久久久不卡| 国产成人精品综合久久久久| 色偷偷偷久久伊人大杳蕉| 精品乱码久久久久久久| 国产精品伦理久久久久久| 色99久久久久高潮综合影院 | 无码日韩人妻精品久久蜜桃| 人妻久久久一区二区三区| 精品久久777| 色综合久久夜色精品国产| 久久久久久综合一区中文字幕| 午夜精品久久久久| 伊人热人久久中文字幕| 亚洲狠狠婷婷综合久久蜜芽| 久久国产成人| 国产综合久久久久| 亚洲日本va午夜中文字幕久久| 精品国产一区二区三区久久久狼| 色婷婷综合久久久久中文字幕| 久久久国产精品福利免费 | 热久久这里只有精品| 国内高清久久久久久| 国产一区二区三精品久久久无广告| 国产aⅴ激情无码久久| 精品久久久久国产免费 | 久久久久一本毛久久久| 伊人久久免费视频| 久久99精品国产99久久6男男| 婷婷久久久亚洲欧洲日产国码AV| 久久精品日日躁夜夜躁欧美| 亚洲精品WWW久久久久久| 激情五月综合综合久久69| 久久青青草原国产精品免费| 69久久精品无码一区二区| 久久精品国产亚洲AV电影| 日韩精品久久无码人妻中文字幕 | 久久精品国产亚洲精品| 国产激情久久久久影院小草| 青青青青久久精品国产h| 99久久伊人精品综合观看|