我具有操作的依赖关系图,并且使用多个队列来组织各种操作流。
例如。 peopleQueue,sitesQueue,sessionQueue

sessionQueue:loginOp,fetchUpdatedAccountOp
peopleQueue:mostFrequentlyManagedClientsOp,其余ClientsOp
sitesQueue:mostFrequentlyAccessedSitesOp,其余SitesOp

依赖项:

*all* -> loginOp
remainingClientsOp -> mostFrequentlyManagedClientsOp
remainingSitesOp -> mostFrequentlyAccessedSitesOp

当前设置有效:登录完成后,所有其他操作将启动
mostFrequently *是子集提取功能,可实现快速的应用响应,后续操作会在后台提取更多数据(有时以页为单位)。

最近,我以为我要添加一个依赖于所有叶子操作的操作。
此最新操作将充当哨兵,告诉我图形遍历何时完成(触发该操作会在NSNotification帖子或其他内容上引起)。所以:
sentinelOp -> remainingClientsOp, remainingSitesOp, fetchUpdatedAccountOp

但是,我发现即使所有依赖项都已完成,哨兵操作也从未启动/触发。
哨兵当时在sessionQueue上排队(没有特殊原因)。

在调试器中玩了之后,我发现如果哨兵仅依赖于同一队列中的操作,则只能将其触发。

通过为该操作引入第4个队列,我终于使哨兵得以运行。
标记取决于它们各自队列中的其他3个叶子操作,然后在它们全部完成时被调用。

我可以采用这种工作模型,但确实让我感到困扰。
适用于Mac和iOS的Apple docs建议应使用队列间依赖性。

我将需要进一步扩展该图,因此令我感到困扰的是,将现有队列用于队列间依赖关系会阻止该操作执行。
显然,队列间的依赖关系在某种程度上起作用了,因为我让loginOp成为了其他操作的根依赖关系,而不管它们排在哪儿。

通过将哨兵操作放在现有的3个队列之一上,我在做什么错?

最佳答案

我仅使用1个队列解决了此问题。我仍然无法理解原始实现的问题,但是我学到了几件事,消除了对多个队列的需求。

首先,使用KVO观察待处理操作的队列数在某种程度上很简单。这就是我能够消除哨兵的方式(请参阅Reference)。

其次,我维护了几个队列,以便从逻辑上分离出相关的操作。通过一个队列,我通过将操作生成方法组合为帮助器方法获得了几乎相同的结果,每个逻辑单元为1,然后对帮助器返回的所有操作进行排队。

我不确定从3个队列到1个队列是否会对性能产生影响。据我所知,只要操作是并发的并且队列对当前执行没有限制,那么操作是否为分布在多个队列中或全部分布在同一队列中。

关于ios - 依赖于不同队列上的另一个操作的NSOperation无法启动,我们在Stack Overflow上找到一个类似的问题:https://stackoverflow.com/questions/20576930/

10-10 23:25
查看更多