• <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精品久久精品一区二区| 久久91综合国产91久久精品| 99久久成人18免费网站| 久久e热在这里只有国产中文精品99 | 久久综合色区| 久久99精品国产麻豆| 国产巨作麻豆欧美亚洲综合久久| 久久精品视频91| 午夜精品久久久久久久久| 99久久免费国产精精品| 久久人人爽人爽人人爽av| 国产高潮国产高潮久久久| 国产精品久久久久久久人人看| 婷婷伊人久久大香线蕉AV| 精品久久久久久久久久久久久久久 | 国产精品免费久久久久影院| 伊人伊成久久人综合网777| 日本精品久久久久中文字幕| 77777亚洲午夜久久多喷| 久久精品中文字幕有码| 狠狠干狠狠久久| 欧洲精品久久久av无码电影 | 中文字幕久久波多野结衣av| 精品综合久久久久久88小说| 国产欧美久久一区二区| 久久综合狠狠综合久久| 思思久久99热只有频精品66| 久久福利片| 久久996热精品xxxx| 精品久久人人做人人爽综合| 成人资源影音先锋久久资源网| 亚洲AV成人无码久久精品老人| 香蕉久久夜色精品国产尤物| 国产亚州精品女人久久久久久| 久久九九亚洲精品| 91久久精品视频| 亚洲精品无码久久久久AV麻豆| 中文精品99久久国产| 久久精品免费一区二区|