Issues with IOS Core data multithreading concurrent access

As we all know, core data itself is not a concurrency-safe architecture, but Apple gives a lot of guidance for the problems of multithreaded access, and many third-party developers contribute a lot of solutions. However, recently encountered a problem very strange, feel that there is a certain particularity, share with you.

The problem seems to have not existed in previous versions of 7.0.1, but later I upgraded the version to 7.0.4. The app model is simple, the main thread reads and writes the database at the foreground, and the latter thread keeps scanning (read-only). A nsmanagedobjectcontext is created for each of the threads.

This model is a bit strange, because the common model is upside down--the background thread does read and write updates, and the main thread reads only, but because of the particularity of my app and the reading and writing performance is not critical, I don't want to spend much effort to distort the logical nature of the structure, or maintain the model. But that's the problem: I found the data written by the main thread, and the background threads didn't read the same, but instead wrote the previous values, even though I did a full fetch again.

According to the Apple documentation and other third-party information, the main program with context save, this change must be persistent, then how can background thread fetch read out the previous value? The machine is not wrong, since the read is the previous value, then it must be the background thread of the context where the cache a copy. But the fetch operation should return the value in the persistent store anyway? And the modification of the insert/delete operation, indeed all reacted, only the property value of the modification, or the old value;

A number of third-party discussion articles on concurrency issues show the opposite problem: if you make changes in the background thread, you need to merge to the main thread. However, this merge affects only the content of Nsfetchresultscontroller, for the consequences of non-merge, all articles are unanimous: unless Re-fetch or re-fault, otherwise the data will certainly be inconsistent. In other words, if the re-fetch, then the data can be consistent. However, the actual test proves that even if it is re-fetch, the value of change cannot be reflected.

Ultimately only doubt that Re-fetch is still not completely re-load the entire model from the persistent storage. Although the object of Insert/delete has indeed been re-load, the property of the change has not been updated; the mechanism of nsmanagedobjectcontext to fetch implementation, You should have left a model cache in memory. To completely understand the cache, after reset the context of the background thread, everything is fine.