dispatch_get_current_queue() przestarzałe, czy istnieje alternatywa dla bezpiecznego CoreData?

Question

Wiele osób pytało pytanie o podobnym tytule, ale bardzo różne przeznaczenie:

CoreData wymaga że śledzenie bieżącej kolejki bieżącego wątku i aktualnej NSOperationQueue (jeśli jesteś NSOperation) , jeśli zezwalasz na wywołania metod pochodzące z innych klas (które domyślnie każda klasa pozwala). Nie ma żadnych "maybes" na ten temat: jest to trudne wymaganie.

To dobrze, i ogólnie jest to łatwe, aby zapewnić:

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"); 

... chyba, że ​​Apple ma i przestarzałej dispatch_get_current_queue(), podobno „, bo ludzie nadużywają go obejść brakuje funkcjonalność w GCD/bitów GCD, których nie rozumieli ".

Uwaga: moje użycie metody dispatch_get_current_queue() powyżej wydaje się być poprawne i nie jest obraźliwe, sądząc po komentarzu do nagłówka Apple: chodzi o to, że sprawdzam, czy kolejka jest prywatną, którą utworzyłem (co twierdzi Apple). jest dopuszczalnym użytkowaniem).

Pomijając mądrość wycofania czegoś po prostu ze względu na błędy w jego implementacji :(... ktoś znalazł sposób obejścia tego problemu przez Apple, w szczególności: z CoreData, musisz śledzić kolejkę - czy jest inny sposób to zrobić:

(ma to znaczenie, ponieważ: w przypadku CoreData, jeśli pozwolisz, aby coś przypadkowo wywołało taką metodę, nie dostaniesz "awarii", dostaniesz "dane zepsute, które pojawią się na . pewnym momencie w przyszłości, kiedy jest już za późno, by to naprawić ")

Answer 1

performBlock zawsze uruchomić go w prawidłowym wątku Wystarczy użyć:

[yourManagedObjectContext performBlock:^{ 
//do your stuff here 
}]; 

Nie potrzebujesz już bieżącego kontekstu bieżącego, ponieważ twój MOC wie, który wątek podpala ten MOC na pierwszym miejscu. Podczas korzystania z performBlock lub performBlockAndWait jesteś bezpieczny.

Answer 2

W moim konkretnym przypadku Wymieniłem wszystkie połączenia performBlock według:

1. poruszające wszystkie działania CoreData do jednej klasy
2. tworząc prywatną dispatch_queue
3. łączących wszystkie moje wewnętrzne połączenia w jeden zadzwoń:
4. pojedyncza rozmowa sama się zawiązuje w dispatch_async ((prywatna wewnętrzna kolejka))
   1. ... i pierwsza rzecz, którą robi wewnątrz dispatc h to "if (self.privateMOC == zero)" ...i tworzy lokalną MOC, gwarantując, że MOC tylko zawsze jest dostępny i creatd na tej jednej kolejce

się dwie rzeczy:

1. mutex/zawiesza lock wszyscy zniknęły (choć może to być zbieg okoliczności - poinformuję później, jeśli okaże się, że blokady są nadal blokowane). Wydajność wydaje się zauważalnie lepsza niż w przypadku performBlock: wszędzie jest używana
   1. UWAGA: mieliśmy wiele wywołań performBlock i robiliśmy to często (wrażliwe dane, które wymagają zmiany zawartości MOC CoreData przy umiarkowanie wysokiej częstotliwości). Nie wiem, czy byłoby zauważalnej różnicy w normalnej aplikacji

... tak, na razie, do moich celów: to okazało się dobrym rozwiązaniem. Nie sądzę, że jest to "właściwa" ogólna odpowiedź na to pytanie, ale ... polecam ją każdemu, kto uzna, że ​​"performBlock" jest mniej panaceum, niż się wydaje.