Должен ли родительский ManagedObjectContext Core Data разделять тип параллелизма с дочерним контекстом?

Могу ли я установить родительский контекст моего ManagedObjectContext в ManagedObjectContext с другим типом параллелизма? Например:

backgroundManagedObjectContext_ = [[NSManagedObjectContext alloc] initWithConcurrencyType:NSPrivateQueueConcurrencyType];
[backgroundManagedObjectContext_ setPersistentStoreCoordinator:coordinator];
managedObjectContext_ = [[NSManagedObjectContext alloc] initWithConcurrencyType:NSMainQueueConcurrencyType];
[managedObjectContext_ setParentContext:backgroundManagedObjectContext_];

Моя цель - (надеюсь) получить быстрое сохранение для managedObjectContext_ (поскольку ему нужно сохранять вещи только в родительский контекст в памяти), а затем заставить backgroundManagedObjectContext_ выполнять сохранение в своей собственной очереди. Если только мне не понадобится выполнить еще одно сохранение из "передней" очереди до того, как сохранится фоновая очередь, мой пользователь никогда не увидит длительного времени сохранения.

Я сталкиваюсь с тем, что выглядит как тупики, но я не уверен, связаны ли они с этим, или моя проблема в другом месте.

Детали для одного места, где я могу более или менее надежно создать тупик:

У меня есть управляемый объектный контекст для главного потока, он поддерживается управляемым объектным контекстом с частным типом параллелизма очереди, и у него есть постоянное хранилище.

У меня есть несколько типов сущностей (около 5), каждый из которых имеет одну или две двунаправленные связи с другой сущностью.

Мое приложение хочет использовать iCloud (я набрал код для этих тестов), поэтому оно не может поставляться с предварительно заполненной базой данных, оно должно создать ее, когда обнаружит пустую.

Поэтому, когда я вижу пустую базу данных (это проверяется в главном потоке), я добавляю около 4 или 8 всех типов сущностей, кроме одного, и этот последний получает около 100 (все добавления происходят в главном потоке). Главный поток выполняет saveContext. После его завершения (без ошибок) он просит другой управляемый контекст объекта запустить блок, который также выполняет saveContext. Этот saveContext определенно является участником тупика. Это также ЕДИНСТВЕННОЕ действие, выполняемое с "фоновым" NSManagedObjectContext вообще.

Точный поток управления после этого немного мутный, поскольку NSFetchedResultsController (все сущности данного типа (который имеет ~3 члена) с простой сортировкой и размером партии в 20 или около того) управляют следующим раундом активности Core Data, но есть вызов от TableViewController, спрашивающий, сколько элементов ему нужно обработать, что является "сколько результатов имеет контроллер fetched results". Этот вызов является другой стороной тупика. (все это происходит в основном потоке)