我已經閱讀了 wiki 上的讀者-作者鎖 - https://en.wikipedia.org/wiki/Readers–writer_lock但嘗試只使用一個計數器和一把鎖。
我很想知道這個實作是否有效。如果是，您認為這足以進行技術面試嗎？
read() {
lock g;
while (num_of_writers > 0) {
g.wait(); // always yield to writers
}
doRead();
unlock g;
}
write() {
lock g;
numOfWriters ; // let all the writers to queue up here
unlock g;
lock g;
doWrite();
num_of_writers--;
g.notify();
unlock g;
}
uj5u.com熱心網友回復：
您的實作看起來像是正確地實作了一個有效的鎖，但它并沒有可靠地確定作者的優先級（如您的標題所述）。
特別是，imaginedoWrite()是一個當前正在執行的長時間運行的操作num_of_writers==1。在其執行期間，許多新的讀取器和寫入器執行緒到達read()orwrite()呼叫。當當前 writer 解鎖g時，可能有幾個 writer 在他們的第一個陳述句上排隊lock g，但是這些 writer 不會優先于在lock gor排隊的 readers g.wait()。事實上，根據notify/wait條件變數的實作，優先級實際上可能會給予g.wait().
此外（也許是最重要的），此代碼不允許并發讀取（doRead()在關鍵部分內執行g），因此從技術上講，這甚至不是讀寫鎖。
Wrt 技術面試，這是一個不錯的反例...給可以在幾分鐘內說出這些缺陷的候選人加分，并雇用可以修復這些缺陷的人；-)
uj5u.com熱心網友回復：
我很想知道這個實作是否有效。
不，這是無效的。它不允許“讀者”共享對資源的訪問，也不能可靠地給予“作者”優先權。有關這兩個問題的詳細資訊，請參閱 Dan Bonachea 的回答。
轉載請註明出處，本文鏈接：https://www.uj5u.com/gongcheng/535809.html
標籤：多线程并发同步信号