QMutexLocker是否返回錯誤代碼（如果有）？

http://doc.qt.io/archives/qt-4.7/qmutexlocker.html QMutexLocker是否返回錯誤代碼（如果有）？

該類鎖定互斥在其構造，所以如果在創建互斥量出現錯誤，我們就可以知道什麼樣的錯誤是它（構造函數不返回任何東西）？

這是一個缺點，不知何故？

我缺少一點嗎？

2012-08-13 Aquarius_Girl

如果你擔心了'bad_alloc'，那麼首先創建互斥量，測試，創造了更衣室之前。你特別擔心發生什麼？ – cmannett85 2012-08-13 12:02:55

@ cbamber85我認爲QMutexLocker類可以「安全地」使用 - 而不用擔心「任何事情」！如果不是在構造函數中鎖定互斥鎖，而是將其鎖定在一個單獨的返回錯誤代碼的類函數中，它會是一個糟糕的設計嗎？ – 2012-08-13 12:05:41

QMutexLocker需要一個指針（並與交易）一個QMutex對象 - 不是pthread_mutex_t對象（即使a QMutex可以在上面實現的pthread_mutex_t）。

鎖定/解鎖QMutex對象不返回任何類型的錯誤代碼（QMutex::lock()和QMutex::unlock()返回void）。

任何可能發生在較低「pthread級別」的錯誤都將由QMutex對象在內部處理，導致C++異常，或者導致代碼中出現缺陷（例如死鎖）（例如，if您嘗試遞歸獲取不遞歸的QMutex）。

來源

2012-08-13 19:25:03

所以這是不安全的使用，這意味着！我被Qt的一部分所左右。 – 2012-08-14 03:28:07

Qt使設計選擇不會爲了一個不錯的API提供某些類型的錯誤處理 - 最值得注意的是它不使用異常。但是，剛剛查看了相關的Qt源代碼（如果您有疑慮，我建議您也這樣做）：EBUSY不相關，因爲它僅適用於tryLock（）。 EAGAIN也不適用，因爲Qt使用自己的計數器進行遞歸鎖定。其他錯誤當然可能發生，但他們極不可能。如果您需要這種錯誤檢查級別，您需要找到另一種解決方案，但對絕大多數用途來說它是「安全」的。 – 2012-08-14 09:14:09

你可能會混淆互斥和鎖。 互斥體是共享同步對象。鎖是LO CAL目的，本地爲每個執行上下文，其效果同步通過鎖定COM 週一互斥的手段。因此互斥已經以存在的鎖是有道理的：

Foo sharedData;   // \ global/ 
QMutex sharedDataMX;  ///shared 

void run_me_many_times() 
{ 
    QMutexLocker lk(&sharedDataMX); 

    // access "sharedData" 
}

來源

2012-08-13 12:06:00

感謝，但'pthread_mutex_lock'返回幾種類似EBUSY等錯誤，所以，互斥變量可能是現有的肯定，但仍可能會出現錯誤，如 - EAGAIN – 2012-08-13 12:09:27

一個簡單的SBRM櫃類喜歡你'QMutexLocker'不適合複雜鎖定語義。它所做的只是提供一個簡單的鎖定/解鎖。如果您需要更精緻的東西，您需要直接連接互斥鎖（例如某種形式的'try_lock'）。一個C++風格的簡單'lock（）'不能失敗，除非通過一個異常，所以如果你的代碼流過'lock（）'調用，你就保證有鎖。 – 2012-08-13 12:11:13

QMutexLocker是否返回錯誤代碼（如果有）？

回答

相關問題