用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）？