それらは同じであるべきですか？親にはどのような種類の同時実行タイプがありますか?
子が executeFetchRequest を実行するたびに、親が尋ねられます。さまざまなスレッドの複数の子が同じタイプで executeFetchRequest を実行するとどうなるでしょうか?
親がメインの同時実行型を持つように宣言され、別のスレッドの子が executeFetchRequest を実行するとどうなりますか? メインスレッドが実行されるまで待ってから結果を出し、スレッドを続行しますか? なにかの？
基本的に、私はさまざまな待機ロックの問題を抱えており、これについてもっと理解したいと思っています。
実際、マルチスレッドの親子関係に関する一般的な慣行に関するリソースがウェブ上にある場合、私はぞっとします。IOS5 では、performBlock を実行する必要があります。ここでコードの多くの変更を意味するため、コアデータのすべてのコマンドでそれを行う必要がありますか?
アップデート：
親/子コンテキストの使用に関する詳細は、次のように記載されているCoreDataリリースノートドキュメントに記載されています。
したがって、スレッド制限タイプで作成された親コンテキストを使用することはできません（「管理対象オブジェクトコンテキストの同時実行サポート」</a>を参照）。
したがって、質問に答えるには、親コンテキストの同時実行タイプがNSPrivateQueueConcurrencyTypeまたはNSMainQueueConcurrencyTypeである必要があります。子コンテキストは、任意の同時実行タイプを持つことができます。
優れた概要と多くのサンプルコードについては、MarcusZarraのCoreDataビデオコースまたは彼の本のベータ版をチェックしてください。
Appleは、 WWDC 2012ビデオと、親と子のコンテキストに関するリリースノート以外の実際のドキュメントをリリースしていません。ビデオでは、それらの使用方法と、performBlockまたはperformBlockAndWaitを使用する必要があるまれなケースについて詳しく説明しています。
ほとんどの人が見逃している重要なことは、同時実行タイプは、コンテキストが作成されたスレッドではなく、コンテキストがコアデータスタックの残りの部分にアクセスするために使用するスレッドを参照することです。スレッド制限パターンを実装し続ける限り、独自のコードでperformBlockまたはperformBlockAndWaitを使用する必要はほとんどありません。これを行うと、デッドロックが発生することがよくあります（特に、1つ以上のコンテキストがNSMainQueueConcurrencyTypeの場合）。
NSMainQueueConcurrencyType -UIで使用されるNSManagedObjectsに適しています。これらのうちの1つだけを維持する必要があります。
NSPrivateQueueConcurrencyType-バックグラウンド操作に適しています。外部ファイルまたはWebサービスから新しいオブジェクトをインポートする場合、parentContextがメインのUIコンテキストになります。オブジェクトの作成が終了するsaveと、変更がparentContextに自動的に通知されます。UIをブロックせずに、ディスクからストアをロードおよび保存するためのUIコンテキストの親としてプライベートコンテキストを使用することもできます。
したがって、子コンテキストを作成してフェッチ要求を実行すると、スレッド（同時実行タイプで指定）を使用して親コンテキストと自動的に対話します。自動的にperformBlockを適切に使用します。子コンテキストを保存すると、親コンテキストは、親コンテキストで何もしなくても、変更が自動的にマージされます。
PerformBlockまたはperformBlockAndWaitを使用する必要がある場合は、スレッド制限パターンを使用しなくなります。スレッド制限パターン内で有効なのは、親に複数の子があり、1つの子の変更が親に保存され、親がそれらを他の子にプッシュする「いとこ」コンテキストに到達する場合のみです。