2012-09-12 57 views
3

我在遞歸模式下使用QReadWriteLock。QReadWriteLock遞歸

此代碼本身並沒有什麼意義,但我已經在這裏出現的問題:

lock->lockForWrite(); 
lock->lockForRead(); 

lockForRead被阻止。請注意,這是遞歸模式。

我看到它的方式是Write是一個「優越」鎖,它允許我讀和寫受保護的數據,其中Read lock只允許讀取。

此外,我認爲寫鎖不應該被阻止,如果唯一的讀者是同一個請求寫鎖。

我可以從qreadwritelock.cpp源代碼中看到,沒有嘗試使它像我想要的那樣工作。所以這不是一個錯誤,但我發現一個功能缺失。

我的問題是,這種遞歸應該允許嗎?這種實現是否會產生任何問題?它們會是什麼?

+0

QT 4.8.0 VS 2005,WIN XP 32位 – 0xbaadf00d

+0

我是新來的Qt,你能告訴你這是什麼'遞歸mode'是什麼意思? –

+0

這意味着我可以從同一個線程多次鎖定相同的互斥鎖,鎖定鎖定和解鎖解鎖解鎖。在非遞歸模式下,第二個鎖將被阻塞。 – 0xbaadf00d

回答

3

QReadWriteLock docs

注意,試圖鎖定 遞歸當鎖類型不能改變,即它無法鎖定在一個線程 已經鎖定了寫閱讀(反之反之亦然)。

所以,就像你說的那樣,它就是它的工作方式。我個人無法看到如何允許在同一個線程上讀寫鎖定項會導致問題,但是可能它需要低效的鎖實現?

你可以試試在QT論壇上提問,但我懷疑你會得到一個明確的答案。 你爲什麼不把QT的源頭作爲首發,並且在你需要的時候去實現自己。編寫同步對象可能會很棘手,但這是一個很好的學習練習。

+0

我看了一下,有一個小問題。爲了允許已經寫入鎖定鎖的讀取類型鎖定對於當前代碼很容易實現。但最難的部分是處理解鎖,因爲現在我不得不記得上次做了什麼樣的鎖定。目前的實施方法有點瑣碎,並沒有提供一個簡單的平臺來實現這一點。我沒有真正關注它,所以也許一個有效的解決方案並不困難。 – 0xbaadf00d

1

我在搜索自己的功能時發現此問題。 一邊想着我自己實現這一點,我意識到,,肯定是有問題產生這樣:

所以,你希望從共享(讀取)獨家(寫)升級鎖。這樣做

lock->unlock(); 
lock->lockForWrite(); 

是不是你想要的,因爲你想沒有其他線程獲得寫入鎖之後當前線程釋放讀鎖。但如果出現這種情況,您將創建一個死鎖。要獲得寫入鎖定,鎖定會阻止,直到釋放所有當前的讀取鎖定。所以在這裏,多個線程將阻止彼此等待。

+0

我喜歡那個「changeModus」的想法。我不確定這是否會導致性能問題。前段時間我經歷過一次代碼,我記得有些性能問題,但我不記得它是什麼,因此我不知道它是否會影響這個。 – 0xbaadf00d