讀寫器鎖執行

我有一個作業問題，我必須實現讀寫器鎖。請注意，我不查找/要求代碼。我希望瞭解讀寫器鎖的行爲，這將幫助我確定實現細節。讀寫器鎖執行

假設獲取鎖的請求遵循以下順序：爲了防止飢餓，我們是否應該按照相同的順序處理請求？如果我選擇跳過寫請求（從而給予讀者更高的偏好），我如何確保寫作者線程不會餓死？

如果給作家一個更高的偏好，我認爲讀者線程有可能會餓死。

我認爲我目前的計劃適用於像RRRRWRRRRWWWRRRRR，WWWWWWRRRRWRRRR，RRRRRRR，WWWWWWW，RWRRR，WRWWW等等的序列。

我還沒有考慮其他情況嗎？ - 我知道這是一個難以回答的問題。因爲我沒有透露任何細節，也沒有列舉我考慮過的所有場景。請多多包涵！

來源

2012-02-21 Neo

在一個理想的世界中，爲所有傳入的讀取提供服務的時間將比最長的正在讀取的讀取時間短。你無法預測，但是你可以做一些適應程序行爲的動態方法。 – Flexo 2012-02-21 17:43:54

「較高的優先級」只有在等待時間沒有限制時纔會產生飢餓。

如果任何線程可以等待的時間量被限定爲某個有限值，那麼該線程將不會餓死。

所以，只要你跟蹤線程何時進入隊列，並且不讓他們等待「太長時間」，就可以在一般情況下（或相反）「優先考慮編寫者的優先級」，而仍然沒有造成活鎖。

通過在拍攝作家之前只服務最大數量的讀者可以獲得相同的效果，反之亦然。

來源

2012-02-21 17:49:10 Borealid

在讀寫器系統中飢餓的常見原因是存在「共享」鎖，允許多個閱讀器鎖定相同資源的鎖。

writer reader1 reader2 

      LOCK_SH 
      obtained 
LOCK_EX  |  
waiting  | 
    :  |  LOCK_SH 
    :  |  obtained 
    :  |   | 
    :  -------  | 
    :     | 
hungry LOCK_SH  | 
    :  obtained  | 
    :  |  ------- 
    :  | 
    :  |  LOCK_SH 
starving |  obtained 
    :  -------  | 
    :     | 
         ...

如果是簡單的優先考慮一方或另一方的事，你可以簡單地有兩個隊列，一個讀者，一個作家，全心全意X讀者（如果有的話正在等待）對於每個Y作家（如果有的話）。

來源

2012-02-21 17:48:47 ikegami

感謝齊格小圖池上。我認爲這兩個答案都很好。我隨機挑選了一個正確的。太糟糕了，我不能同時接受。 :) – Neo 2012-02-21 18:37:33

@Neo，謝謝 – ikegami 2012-02-21 18:56:13

讀寫器鎖執行

回答

相關問題