用NSOperationQueue解决读者 - 作家问题？

Question

我知道可以使用障碍解决GCD中的读写器问题.由于我(通常)NSOperationQueue在性能不是关键问题时尝试使用而不是GCD,我想要一个NSOperation兼容此问题的兼容解决方案.

我试着写自己的,但我的解决方案变得笨拙......当然有人已经解决了这个问题吗？

有没有人知道NSOperation兼容读写器问题的解决方案？

Answer 1

与大多数NSOperationQueue黑客一样，您可以利用它对操作之间依赖关系的支持：

• 创建一个NSBlockOperation子类，ReaderWriterBlockOperation. 添加到它的属性BOOL writer。
• 每个受保护资源创建一个操作队列。
• 停止向客户端公开您的操作队列。相反，公开 API-readWithBlock:和-writeWithBlock:. 两者都入队 an ReaderWriterBlockOperation，一个与writer == NO另一个== YES。他们的操作管理依赖关系如下：
  • -readWithBlock:在块中@synchronized(self)，从最后到第一个扫描操作以查找写入器块。如果没有找到，则添加操作并返回。如果找到，它会使新的读取器块依赖于写入器，将其排队并返回。
  • -writeWithBlock:做同样的事情。除非在排队的操作中找不到写入器，否则该块将依赖于找到的所有读取器。如果在排队的操作中找到一个操作，则它会使自己依赖于该操作以及所有后续（读取器）操作。

这应该导致阻塞所有读取器直到它们之前的写入器完成，并阻塞所有写入器直到它们之前的读取器完成。

一个可能的问题：我不清楚（因为文档不清楚，而且我还没有实现这一点）是否实际上NSBlockOperation等待其块完成运行然后再声明其完成。如果没有，您需要在操作子类中自行管理。

尽管如此，如果系统提供了可行的解决方案，例如障碍块，您应该使用它。整个系统是一个让操作队列去做一些事情的黑客，而调度队列已经被调整为可以很好地处理。如果性能实际上不是一个问题，那么为什么不只使用串行队列（NSOperationQueue最大并发操作数== 1）呢？