CODEWITHSUNDEEP
objective-cmultithreadingcore-data
Mark Wheeler
Mark Wheeler

Reputation: 697

Better to not use Core Data for ease of thread safety?

I have an app that is currently built on Core Data and has multiple threads with multiple NSManagedObjectContexts. It's a music app so there is always stuff running on the background threads that needs to not interfere with the main thread and vice versa.

So far I've been slowly chipping away at all sorts of deadlock & thread safety issues, but frankly I'm hitting a wall in trying to keep MOCs in sync and have them not block threads, and nothing access entities that have been deleted etc.

My question is this: If I were to ditch Core Data and just create some custom NSObjects to keep track of properties would that make these kind of issues simpler? Is it possible to access the NSObjects from multiple threads (without causing deadlock etc) so that I wouldn't have to maintain several copies and sync them? Or will I still face similar challenges?

I'm pretty new to objective-c so i'm really looking for the easier solution rather than the most sophisticated. Any links to good designs patterns for this sort of thing also appreciated!

Upvotes: 1

Views: 138

Answers (1)

bbum
bbum

Reputation: 162712

Rephrasing the question: "Would we be better off ditching a framework where the engineers, whose sole focus is on creating said framework, have spent countless hours working on that framework's concurrency model to instead roll our own concurrency model, starting from scratch?"

Concurrency is hard.

Rolling your own means tackling all the problems that Core Data has tackled already (including accessing state from multiple threads without deadlocking and/or requiring many copies of the data) and then adding on whatever unique twists you need for your app. The team that wrote Core Data has thought quite deeply about the subject, to the point that there is an entire set of documentation devoted to it (with the APIs to back it).

So, certainly, there is quite likely a concurrency model that would be highly specific to your application that would be considerably more efficient than using Core Data, but you are going to end up re-inventing the persistency patterns Core Data currently offers you and you'll need to engineer said concurrency model from the ground up.

So, no, there is no easy way out.

Given that it is a music app, I can fully appreciate how difficult the concurrency issues can be. Latency is obviously a huge issue. You'll need to ask a more specific architectural/design question to really glean much insight beyond the above.

For example, what granularity of data are you persisting via Core Data and what is the frequency of change of said data? Is the model of said data relatively optimal? Etc.etcetc...

Or, with a concrete example:

Say you have a Note class that describes a note to be played. Say that note has properties like pitch, volume, duration, instrument, etc...

Now, imagine your background thread needs to set pitch and duration.

Without thread synchronization of some kind, how would the consuming thread know that the editing thread is done editing?

Upvotes: 5

Related Questions