用NSOperationQueue解決讀寫器問題？

Question

我知道有可能使用障礙來解決GCD中的讀寫器問題。由於我（通常）嘗試使用NSOperationQueue而不是GCD，因此在性能不是關鍵問題時，我想要一個兼容NSOperation的解決方案來解決此問題。

我試圖寫我自己的，但我的解決方案已變得笨拙......當然有人已經解決了這個問題呢？

有誰知道NSOperation兼容解決方案的讀寫器問題？

Answer 1

與大多數NSOperationQueue兩輪牛車，你可以利用它支持業務之間的依賴關係：

• 創建NSBlockOperation子類，ReaderWriterBlockOperation。添加到它屬性BOOL writer。
• 爲每個受保護資源創建一個操作隊列。
• 停止將您的操作隊列公開給客戶端。而是暴露API -readWithBlock:和-writeWithBlock:。這兩個排隊ReaderWriterBlockOperation，一個writer == NO，另一個== YES。它們的操作如下管理相關性：
  • -readWithBlock:在@synchronized(self)塊中執行從最後到第一次查找寫入程序塊的操作的掃描。如果沒有找到，它會添加操作並返回。如果找到一個，它會使新的閱讀器塊依賴於作者，將其排入隊列並返回。
  • -writeWithBlock:做同樣的事情。除非在排隊的操作中找不到作者，否則它會使塊依賴所有找到的讀者。如果在排隊操作中找到一個操作，它就會依賴於該操作和所有跟隨（讀取器）操作。

這應該阻止所有的讀者，直到作家完成之前他們，並阻止所有的作家，直到讀者他們已經完成了之前的結果。

一個可能的問題：如果NSBlockOperation實際上在聲明自己完成之前等待其塊完成運行，我還不清楚（因爲文檔不清楚，並且我還沒有實現此目的）。如果沒有，你需要在你的操作子類中自己管理它。

所有這一切說，如果系統提供了一個工作解決方案，如障礙塊，你應該使用它。這整個系統是一個黑客，讓操作隊列做一些調度隊列調整處理得很好的東西。如果性能實際上不是問題，那麼爲什麼不使用串行隊列（最大併發操作數== 1的NSOperationQueue）？