从多个线程将对象加载到一个托管对象上下文会出现什么问题？
好的，所以我有多个线程将数据从持久存储（SQLite 数据库）提取到单个 NSManagedObjectContext (MOC) 实例中。我已经对其进行了相当彻底的测试，在操作重叠的情况下（线程 4 加载到 MOC，而线程 5 也加载到 MOC），一切都运行顺利。
我已经阅读了（大部分）核心数据编程指南，并且知道苹果不会纵容这种行为，但我想知道具体原因是什么。苹果在文档中简要提到了这样一个事实：不仅写入是危险的，读取也是危险的，因为可能会发生错误。如何（如果我从单独线程加载的所有对象都是彼此不重叠的单独实体）？这难道不是意味着该应用程序的性能会受到影响吗？因此，如果我确定性能下降比增加内存使用更好，我会倾向于使用单一 MOC（不推荐）方法。
无论如何，我都会恢复推荐的方法，但我只是好奇如果不遵守这些规则可能会发生什么的具体细节。提前致谢。
Ok, so I have multiple threads pull data from the persistent store (SQLite database) into a single NSManagedObjectContext (MOC) instance. I have tested it pretty thoroughly and in the case where operations overlap (thread 4 loads into the MOC while thread 5 does so too), everything runs smoothly.
I have read (most of) the Core Data Programming guide and am aware that Apple does not condone this behavior, but I am wondering what the particular reasons are. In the docs Apple briefly alludes to the fact that not only writes are dangerous, but reads are as well because faulting may occur. How (if all the objects I load from the separate threads are individual entities with no overlap with each other)? And doesn't that just mean that the app will take a performance hit? So if I determine that a performance hit is a better tradeoff than increased memory usage, I would be inclined to use the one MOC (non-recommended) method.
I am going to revert to the recommended method in any-case but am just curious about the specific details of what could happen if these rules aren't adhered to. Thanks in advance.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我真的不知道，但是还没有人回答。
不是线程安全的就不是线程安全的。想象一下，Core Data 程序员将一些未公开的实例变量放入 NSManagedObjectContext
numberOfObjectsLoaded中。在线程 A 中，您访问托管对象foo.bar的关系。在线程 B 中，您对一些完全不相关的对象baz.number = 14进行了更改。 foo 和 baz 都是错误。他们被加载了。两个线程都尝试执行该代码行，但线程 A 读取 numberOfObjectsLoaded，得到 77，然后进行上下文切换。线程 B 也读取 77，加 1，分配 78。回到线程 A。它将读取的 77 加 1，得到 78，并将 78 分配给 numberOfObjectsLoaded。 numberOfObjectsLoaded 应该为 79，但实际为 78。这种不一致将导致意外错误，并可能最终导致崩溃。这种情况可能只发生在您运行程序的 1/1000 次，并且可能直到实际错误发生几分钟后才显现出任何不好的情况。非常难以调试。
听从他们的建议，不要尝试。
I don't really know, but since nobody answered yet.
Not thread-safe is not thread-safe. Imagine the Core Data programmers put some unexposed instance variable in NSManagedObjectContext
numberOfObjectsLoaded. In thread A, you access a relationship of a managed object,foo.bar. In thread B, you make a change to some completely unrelated objectbaz.number = 14. Both foo and baz are faults. They get loaded. Both threads try to execute the line of codeBut thread A reads numberOfObjectsLoaded, gets 77, then context switch. Thread B reads 77 also, adds 1, assigns 78. Back to thread A. It adds 1 to 77, which is what it read, gets 78, and also assigns 78 to numberOfObjectsLoaded. numberOfObjectsLoaded should have 79, but has 78. That inconsistency will lead to unexpected errors, and probably eventually a crash. It will only happen maybe 1/1000 times you run your program, and possibly nothing bad will be apparent until several minutes after the actual error occurred. Very hard to debug.
Follow their advice and don't try it.
您是否从数据库中提取了对象，或者是否也尝试访问属性？那就是处理错误的时候......
很可能在某个时候，您的代码会崩溃。
Did you pull the objects out of the database, or did you also try to access properties? That is when faults get dealt with...
It is very likely that at some point, your code will crash.