題目其實可以說清楚這個問題，但是確實是有點長。在看到讀者寫者問題的各種優先順序解決方案（讀者優先，寫者優先，讀者寫者公平）以後聯想到以前思考過的乙個問題，即寫鎖飢餓問題（傳送門），那個問題的本質就是讀者寫者的優先順序問題，且當時找到的對應解法是比較優秀的解法，那篇文章描述的兩種解法其實都可以算是寫者讀者公平的方法（cow算是並行）。那麼有所偏重的優先順序解法該如何做呢？其實也很簡單，這篇文章會使用偽**來一一做解釋，注意使用會訊號量作為同步工具。這篇文章算是對這個問題的乙個小總結，因為原來的那篇文章可以看做這篇文章的乙個拓展，而原來文章的內容現在看來著實是十分有趣的，遂記錄這篇文章，以引出那篇文章，希望藉此讓更多的人對這個問題的看法更深一些。
首先簡單描述一下讀者寫者問題：
讀者-寫者問題是指保證任何寫者程序必須與其他程序互斥的訪問共享的資料物件的同步問題。
從對問題的描述我們可以看出其實讀寫鎖實際上是讀者-寫者問題的乙個實體，且運用是比較廣泛的。
讀者優先意味著當目前存在讀程序的時候寫程序會被無限延後執行，當不存在讀程序的時候寫程序才可以執行，可以簡單的理解為「讀程序插隊」。
其中的wnutex，rmutex是訊號量，使用pv操作（wait，signal），當然就這裡而言看做互斥鎖也是可以的。
我們簡單的分析以下這個過程，當有乙個讀者的時候就把readercount加一，也就是說readercount記錄著現在的讀者數，且在存在讀者的時候wait（wmutex），這樣當存在讀者的時候寫者就無法執行，而在讀者存在的時候所有後來的讀者是可以「插隊」的，這樣就做到了讀者優先。
讀者寫者公平顯然是乙個比較常見的模型，那麼我們如何可以做到讀者寫者公平呢？我在寫鎖飢餓問題中描述了兩種效能優秀的演算法，這裡就不再細談了。我們使用最簡單的加鎖來實現乙個讀者-寫者公平演算法：
我們引入乙個互斥鎖s，在每次讀程序執行的時候要請求s，只有得到才能繼續，對應的，如果寫程序在寫入時也必須拿到s的話就會使得寫程序不執行的話，寫程序之後發生的讀請求就會阻塞了，總而實現公平。但是缺陷顯然也非常明顯，就是所有操作都需要請求s，這樣當操作執行緒多了以後s就會成為瓶頸。
當寫入優先順序較高的時候我們希望寫者優先，實際上這個模型使用我在寫鎖飢餓問題中提到的copy-on-write（不是fork優化的那個）的話效率更高，但當copy成本過高的時候就需要其他的方法了（這樣看來兩篇文章是互補的），這裡使用鎖來完成。
任何乙個讀者被呼叫的時候都需要與寫者競爭s。
其實邏輯和讀者優先的時候一樣，及時使寫程序成為乙個團體，只有在全部的寫操作完成的時候，即writercount==0的時候才會釋放s，這個時候讀者才可以繼續讀，這樣看來就是寫者可以「插隊」，當然第乙個寫者與讀者的競爭與讀者-寫者公平的過程是一樣的。
參考：
讀者寫者問題（讀者優先,寫者優先 ,讀寫公平）
讀者優先的解決方案 互斥訊號量wrt，初值是1，代表乙個共享檔案，解決 讀 寫 互斥，寫 寫 互斥。乙個記數器，即整型變數readcount，記錄讀者數，初值是0。來乙個讀者，readcount加1 當readcount 1表示是第乙個讀者，則需要執行p操作搶占檔案 否則表示已有讀者在安全的讀資料。...
讀者寫者問題的寫者優先演算法
演算法如下 有讀者 reader 和寫者 writer 兩組併發程序，共享乙個檔案，當兩個或以上的讀程序同時訪問共享資料時不會產生 但若某個寫程序和其他程序 讀程序或寫程序 同時訪問共享資料時則可能導致資料不一致的錯誤。因此要求 允許多個讀程序可以同時對檔案執行讀操作 只允許乙個寫程序往檔案中寫資訊...
「讀者 寫者問題」的寫者優先演算法實現
讀者一寫者問題是乙個用訊號量實現的經典程序同步問題。在系統中，乙個資料集 如檔案或記錄 被幾個併發程序共享，這些執行緒分兩類，一部分只要求進行復操作，稱之為 讀者 另一類要求寫或修改操作，我們稱之為 寫者 一般而言，對乙個資料集，為了保證資料的完整性 正確性，允許多個讀者程序同時訪問，但是不允許乙個...