讀寫器鎖的boost :: unique_lock和boost :: shared_lock

Question

我們已經實現了一個讀寫器鎖

 typedef boost::unique_lock<boost::shared_mutex> WriterLock;
 typedef boost::shared_lock<boost::shared_mutex> ReadersLock;

我們有很多多線程讀者，只有少數作家。 讀者與其他讀者共享訪問權限但阻止作者。 Writer阻塞，直到它具有對資源的獨占訪問權限。

我們在增強文檔中找不到這個...防止Writer飢餓的政策是什么？
例如，如果有許多讀者都在從線程池中敲擊鎖定，那么在編寫器最終獲得鎖定之前，鎖定嘗試次數是否有任何保證上限？

我們一直看到性能數字似乎表明寫入必須等到根本沒有讀者，而且很少有情況需要很長時間，因為新讀者可以在當前讀者服務時請求鎖定。 在這種情況下，似乎在我們的代碼中，作者必須等待很長時間才能完全沒有讀取。

我們更喜歡像系統這樣的隊列，當寫入者請求鎖定時，所有當前讀者都會耗盡，但所有新的傳入讀者都會阻止寫入者請求。

Boost中可升級鎖概念的行為是什么？ 提升線程

它沒有說它如何處理作家飢餓。

Answer 1

@ Guerrero解決方案的一個小改進，增加了多個讀者和多個作家的公平性，因此沒有人會餓死：

read() {
    while (atomic-write-requests > 0)
        condition.wait();
    ReadersLock lock(acquireReaderLock());
    doRead();
}
write() {
    while (atomic-write-requests > 0)
        condition.wait();
    atomic-write-requests++;
    WritersLock lock(acquireWriterLock());

    doWrite();
    atomic-write-requests--;
    condition.notify();
}

在這個解決方案中，每當作家離開范圍時，都會開始一場新的公平競爭。

Answer 2

在不了解boost實現的情況下，也許您可​​以通過實現來防止編寫器的飢餓。 讀者可以在作家存在的情況下等待。 也許像這個偽代碼：

read() {
    while (atomic-write-requests > 0) {
        condition.wait();
    }
    ReadersLock lock(acquireReaderLock());
    doRead();
}
write() {
    atomic-write-requests++;
    WritersLock lock(acquireWriterLock());

    doWrite();
    atomic-write-requests--;
    condition.notify();
}

Answer 3

如果你想要的是一個fifo方法，boost在其狀態圖庫上實現了幾種調度策略（包括FIFO）。 我猜你將不得不調整你的很多代碼來使用它。 查看有關fifo_scheduler和FifoWorker的文檔：

http://www.boost.org/doc/libs/1_51_0/libs/statechart/doc/reference.html#FifoWorker

http://www.boost.org/doc/libs/1_51_0/libs/statechart/doc/reference.html#fifo_scheduler.hpp