0

我正在修改我的程序以使用新的 iOS5 样式。

所以我只是使用这段代码：

NSManagedObjectContext *threadContext = [[NSManagedObjectContext alloc] initWithConcurrencyType:NSPrivateQueueConcurrencyType];
threadContext.parentContext = [self managedObjectContextMainThread];
//threadContext.persistentStoreCoordinator= [self persistentStoreCoordinator]; //moc.persistentStoreCoordinator;//  [moc persistentStoreCoordinator];

我的新背景 ManagedObjectContext 没有persistentStore，而是有父存储。\

在那之后我想我应该添加

在我使用所有使用新 MOC 的操作的所有操作上执行 BlockAndWait。

我不使用它，至少到目前为止做得很好

performBlockAndWait 是通过在同一个线程中执行块并等待它完成来完成的。

那和像往常一样输入代码有什么区别？

我的意思是必须有一些使用，但我在这里完全失踪了。

我能理解performBlock。这就像在后台执行某些操作一样。即便如此，它也被 Global Central Dyspatch 所取代。

是的，有一个叫做队列的新东西。好的，如果我们在同一个线程上做某事，当然一切都是连续完成的。呃……那为什么要排队？

有人愿意解释吗？

4

2 回答 2

0

执行块的线程可能与调用 performBlockAndWait 的线程不同。

例如，某些核心数据对象可能只能在主线程中执行。

因此， performBlockAndWait 将在主线程（不同线程）上执行此操作并阻塞当前线程。

也很省钱。核心数据会适当地锁定事物以防止冲突。如果您有多个线程访问同一个托管对象上下文，则需要将其拉起。

于 2013-04-23T00:18:54.510 回答
0

原因performBlockAndWait:是它会获取并持有并发锁来访问 Core Data。您可以将其视为lock/unlock方法的现代化，但这是未记录的实现细节。

如果您只是直接执行代码，它不会进行正确的并发锁定。这很有趣，原因有很多：

  1. 对 Core Data 的请求不会被正确序列化。也就是说，如果您performBlock:（不等待）代码最终可能与其他 Core Data 代码同时执行，这可能会导致协调器或持久存储出现问题。
  2. 它……好吧，我实际上认为它不应该起作用。在大多数情况下似乎在实践中，但是您在没有必要的锁的情况下运行 Core Data。可以肯定的是，您至少在这里遇到了无证行为。

所以：

  • performBlockAndWait:设置一个环境，您的块可以通过上下文访问核心数据并等待块完成。
    • 文档没有说明线程。它实际上并未记录为在当前线程上运行。
    • 即使现在没有，将来至少在某些情况下可以更改为转到辅助线程。
    • 再次阅读父点：这就是您应该依赖的。剩下的只是细节。
  • performBlock:设置一个环境，您的块和通过上下文访问核心数据并且不等待块完成。
    • 文档没有说明线程。它实际上并没有记录为在不同的线程上运行。
    • 虽然不太可能，但操作系统的未来版本可能会决定稍后在当前线程上运行该块。
    • 同样，父点是您要依赖的。其余的是未记录的细节。

我希望这会有所帮助。基本上，当你接触这些电话时，你应该比你更愚蠢。让操作系统做正确的事，尽量不要对它在做什么做出假设。:)

常数对它的NSPrivateQueueConcurrencyType工作方式设置了太多期望。

于 2017-02-02T20:38:04.580 回答