6

多くの人が同様のタイトルで質問をしていますが、目的は大きく異なります。

CoreDataでは、他のクラスからのメソッド呼び出しを許可する場合 (既定ではすべてのクラスで許可されます)、現在のキュー、現在のスレッド、および現在の NSOperationQueue (NSOperation の場合) を追跡する必要があります。これについて「おそらく」というものはありません。これは難しい要件です。

それは問題ありません。一般に、次のことを確認するのは簡単です。

NSAssert( [NSThread currentThread].isMainThread || myPrivateQueue == dispatch_get_current_queue(), @"You tried to call this method from an external thread, or a queue other than my internal private queue. That's not legal, and will cause data corruption" );

...Appleがdispatch_get_current_queue()を廃止し、非推奨にしたことを除いて、明らかに「人々がGCDの欠落している機能/理解していないGCDのビットを回避するためにそれを悪用していたため」.

注: 上記の dispatch_get_current_queue() の私の使用法は、Apple のヘッダー コメントから判断すると、正しく、乱用されていないように見えます: 全体的なポイントは、キューが私が作成したプライベートなものであることを確認していることです (Apple は、これは許容される使用法であると主張しています)。 .

単に実装の欠陥のために何かを非推奨にするという知恵はさておき:( ... Appleによって削除されたこれに対する回避策を誰かが見つけましたか?具体的には:CoreDataを使用すると、キューを追跡する必要があります-それを行う別の方法はありますか? ?

(これは重要です: CoreData を使用すると、何かがそのようなメソッドを誤って呼び出すことを許可した場合、「クラッシュ」が発生せず、「データの破損」が発生し、手遅れになったときに将来のある時点で表示されます。それを修正する」）

4

2 に答える 2

0

私の特定のケースでは、すべての performBlock 呼び出しを次のように置き換えました。

  1. すべての CoreData アクションを単一のクラスに移動する
  2. プライベートdispatch_queueの作成
  3. すべての内部通話を 1 つの通話にマージする
  4. 単一の呼び出しは、dispatch_async( (プライベート内部キュー) ) にラップされます
    1. ...そして、ディスパッチ内で最初に行うことは「if( self.privateMOC == nil )」です...そしてローカルMOCを作成し、MOCがその1つのキューでのみアクセスおよび作成されることを保証します

次の 2 つのことが起こりました。

  1. ミューテックス/ロックのハングはすべて消えました (これは偶然かもしれませんが、ロックがまだデッドロックされていることが判明した場合は、後で報告します)
  2. パフォーマンスは performBlock よりも著しく優れているように見えます: どこでも使用されています
    1. 注: 多くの performBlock 呼び出しがあり、これを頻繁に行っていました (適度に高い頻度で CoreData MOC の内容を変更する必要がある機密データ)。通常のアプリで顕著な違いになるかどうかはわかりません

...だから、今のところ、私の目的のために: これは良い解決策であることが証明されています. それが質問に対する「正しい」一般的な答えだとは思いませんが、「performBlock」が見かけほど万能薬ではないことに気付いた人には、それをお勧めします。

于 2013-08-29T16:54:17.090 に答える