Question

We have a background thread that needs to do some fetching.. but it doesnt need any data — only the objectIDs

originally we did this using a specific newly created blank managed context just for this.

NSFetchRequest *request = [DKDocumentDetails requestAllWithPredicate:predicate inContext:ctx];
[request setResultType:NSManagedObjectIDResultType];
self.objectIDs = [DKDocumentDetails executeFetchRequest:request inContext:ctx];
...

but recently I found out, I can also do this on the PST itself, without any context AS I dont want Managed Objects, but only IDs

NSFetchRequest *request = [DKDocumentDetails requestAllWithPredicate:predicate inContext:mainctx /*used in the wrong thread but only for getting entity description*/];
[request setResultType:NSManagedObjectIDResultType];

NSError *error = nil;
self.objectIDs = [pst executeRequest:request inContext:nil error:&error];
...

so in my tests it never crashed and in the docs I dont see why it shouldnt work either… I mean I dont get unsaved stuff and I cannot get objects, but used this way…

It is faster and looks elegant but is it safe or not?

Answer 1

I’ve been thinking about your question all day. Here is what I’ve come up with. As others have pointed out, NSPersistentStoreCoordinator objects are not thread safe. When a bunch of NSManagedObjectContext objects on various threads use the same NSPersistentStoreCoordinator, they do so by locking and unlocking the NSPersistentStoreCoordinator.

However, you are worried about just reading data, and thread safe NSManagedObjectID data at that. Is that ok?

Well, the Apple documentation On Concurrency with Core Data mentions something similar to what you are doing:

For example, you can configure a fetch request to return just object IDs but also include the row data (and update the row cache)—this can be useful if you’re just going to pass those object IDs from a background thread to another thread.

Ok, but do we need to lock the Coordinator?

There is typically no need to use locks with managed objects or managed object contexts. However, if you use a single persistent store coordinator shared by multiple contexts and want to perform operations on it (for example, if you want to add a new store), or if you want to aggregate a number of operations in one context together as if a virtual single transaction, you should lock the persistent store coordinator.

That seems to be pretty clear that if you are performing operations on a persistent store from more than one thread, you should lock it.

But wait – these are just read operations, shouldn’t they be safe? Well, apparently not:

Core Data does not present a situation where reads are “safe” but changes are “dangerous”—every operation is “dangerous” because every operation has cache coherency effects and can trigger faulting.

Its the cache we need to worry about. That’s why you need to lock – a read in one thread can cause data in another thread to get messed up through inadvertent cache changes. Your code never gave you problems because this is probably really rare. But its those edge cases and 1-in-1,000,000 bugs that can do the most damage…

So, is it safe? My answer:

• If nothing else is using your persistent store coordinator while you read, yes, you are safe.
• If you have anything else using the same persistent store coordinator, then lock it before you get the object IDs.
• Using a managed object context means the locking is automatically taken care of for you, so its also a fine possibility, but it looks like you don’t need to use it (and I agree it is nice to not make one just to get a few Object IDs).