其他线程可以间接访问在其自己的线程中运行的托管对象上下文吗？
Apple 推荐的多线程核心数据方法是为每个线程使用托管对象上下文，并通过将更改的线程上下文保存到共享持久存储来将更改从一个上下文发送到另一个上下文。
虽然我可以想象这很好，例如。 RSS 阅读器，对于某些应用程序来说它似乎远非理想。就我而言，我正在编写一个音乐音序器来记录和播放音乐。使用后台线程播放数据。我需要在记录/播放期间主线程可以访问记录的数据。在录制/播放时必须不断保存和加载数据已经够糟糕的了，更糟糕的是，它似乎迫使用户在录制或播放时都进行保存，这有点让人尖叫“糟糕的应用程序”。
然而，似乎有一种方法可以避免这种情况。如果其他线程不需要访问核心数据实体本身（只需访问它们包含的数据），那么什么可以阻止我在自己的线程中运行托管对象上下文，并且只允许其他线程间接访问，例如通过绑定 UI对象到在托管对象上下文的线程上调用 performSelector:onThread:withObject:waitUntilDone: 来获取/设置值的属性？
它没有提供多线程的一些好处（即将核心数据扩展到多核 CPU），但很多时候，我们只是希望多线程避免在发生密集操作时锁定 UI。
我还没有看到针对核心数据提倡这种模式。考虑到当你不完全按照苹果的建议去做时，它可能是一个奇怪且不可预测的野兽，我认为值得一问的是，这是否真的避免了我们不鼓励多个线程访问单个托管对象上下文的原因。
Apple's recommended method for multithreading core data is to use a managed object context per thread, and to send changes from one context to another by saving the changed thread's context to a shared persistent store.
While I can imagine that being fine for, eg. an RSS reader, for some applications it seems far from ideal. In my case, I'm writing a music sequencer that records & plays data using a background thread. I need recorded data to be accessible to the main thread during record/playback. Having to constantly save and load data while recording/playing would be bad enough, but worse, it'd seem to force the user to save whenever they record or play, which kinda screams 'terrible application'.
However, it seems that there might be a way of sidestepping this. If other threads don't need access to the core data entities themselves (just the data they contain), what's to stop me from running the managed object context in its own thread, and only allowing other threads indirect access, for example by binding UI objects to a property that calls performSelector:onThread:withObject:waitUntilDone: on the managed object context's thread to get/set values?
It doesn't give some of the benefits of multithreading (i.e. scaling core data to multicore CPUs), but a lot of the time, we just want multithreading to avoid locking up the UI while something intensive is happening.
I've not seen this pattern advocated for core data. Given that it can be a strange and unpredictable beast when you don't do exactly what apple suggests, I thought it'd be worth asking if this really does avoid the reasons we're discouraged from letting multiple threads access a single managed object context.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您无法控制 NSManagedObject 内部的实现细节，更具体地说，当您读取属性时，CoreData 可能需要在上下文中执行某些操作。
对于您的特定需求，我建议您使用高度优化的隔离、基于缓冲区和队列的解决方案，在将 CD 对象传递到后台处理线程之前，您可以从 CD 对象中复制所需的内容。
如果需要，您可以使用performSelector:on*Thread:，但随后您将处理同步问题、延迟和其他有趣的并发问题。就我个人而言，我会采用上面描述的排队机制。
You have no control over the implementation details of an NSManagedObject's internals and, quite specifically, there are reasons why CoreData may need to do something in the context when you read an attribute.
For your particular needs, I would suggest a highly optimized isolated, buffer and queue, based solution where you copy what is need out of the CD objects before passing them to a background processing thread.
You can use performSelector:on*Thread: if you want, but then you'll be dealing with synchronization issues, latency, and other fun bits of concurrency. Personally, I would go with the queueing mechanism described above.