Was ist mit CoreData gemeint ist nicht threadsicher?

@ d11wtqs Antwort ist korrekt , nur wenn Sie Ihren eigenen Code schreiben oder Ihre eigenen APIs entwerfen .

Es ist völlig falsch, wenn Sie mit einer Reihe von APIs arbeiten, und ganz besonders falsch bei der Arbeit mit Core Data.

Im Kontext der Arbeit mit Mac OS X und iOS muss die Thread-Sicherheit immer im Zusammenhang mit der Arbeit mit den System-APIs betrachtet werden. Selbst wenn Sie beispielsweise ein NSArray verwenden, bedeutet dies, dass Sie mit den System-APIs arbeiten.

  

ODER im Allgemeinen was ist "nicht Thread   sicher "?

Eine nicht threadsichere API ist eine API, bei der Sie nicht gleichzeitig mit mehreren Threads mit der API interagieren können. Es kann auch zusätzliche Einschränkungen geben, die meistens den Hauptthread betreffen. Beispielsweise müssen fast alle Zeichenoperationen im Hauptthread von Mac OS X und iOS ausgeführt werden.

Die Apple-Dokumentation geht davon aus, dass die Thread-Sicherheit der Ausnahmefall ist. Das heißt, eine API ist nur threadsicher, wenn die Dokumentation explizit Thread-Sicherheit beansprucht . Wenn Threadsicherheit nicht erwähnt wird, müssen Sie davon ausgehen, dass die API nicht threadsicher ist.

  

Was heißt in Obj-C einfach?   Begriffe; "CoreData ist nicht threadsicher"

Diese Aussage ist nicht ganz richtig, aber es ist eine sichere Annahme.

In Core Data ist das Interaktionsverhalten des Threads sehr gut. dokumentiert .

Kurz gesagt, Teile der API sind Thread-sicher (zum Beispiel der Store-Koordinator) und Teile sind ganz explizit nicht Thread-sicher. Während der MOC Methoden zum Sperren und Entsperren bietet, können Sie auch externe Sperren verwenden. Aber nicht. Es wird weniger effizient und anfälliger sein; deutlich so. Verwenden Sie im Allgemeinen auch nicht die interne Verriegelung. CoreData ist optimiert um einen Kontext pro Thread / Queue zu haben.

(Antwort basierend auf der Rückmeldung von TC behoben. Danke.)

AKTUALISIEREN | Bitte beachten Sie die Antwort von @bbum. Ich akzeptiere, dass meine Antwort fehlerhaft ist und @bbum korrekt ist.

Wenn etwas als "nicht threadsicher" beschrieben wird, bedeutet dies, dass keine besonderen Vorkehrungen getroffen wurden, um sicherzustellen, dass es nicht abstürzt, wenn zwei separate Threads versuchen, es gleichzeitig zu verwenden. Im Allgemeinen erfordert Code, der von mehr als einem Thread verwendet werden soll, explizite Sperren (oder @synchronize blocks), die Aspekte des Codes umschließen. Insbesondere würde jedes Objekt / jede Variable, die geändert werden, mit ziemlicher Sicherheit einen Absturz verursachen, wenn zwei Threads gleichzeitig auf sie schreiben würden (da sie in dieselbe Speicheradresse schreiben würden). Wenn ein Thread eine Variable liest, während ein anderer Thread darauf schreibt, wird Müll zurückgegeben und das Programm stürzt wahrscheinlich ab.

Mit @synchronized oder NSLock oder einem POSIX-Mutex usw. wird sichergestellt, dass immer nur ein Thread einen bestimmten Codeblock zu einem bestimmten Zeitpunkt ausführen kann. Die anderen Threads werden blockiert und müssen warten, bis die Sperre aufgehoben wird. Es gibt einen leichten Leistungseinbruch bei der Verwendung von Sperren (und natürlich einige Entwicklungskosten müssen darüber nachdenken), so dass der Code ausdrücklich erklärt, dass er nicht threadsicher ist, sodass Sie, der Anwender des Codes, die Sperren nach Bedarf selbst platzieren können (oder beschränken Sie die Ausführung des nicht Thread-sicheren auf einen einzelnen Thread).

Weitere Informationen zu Threading und Thread-Sicherheit finden Sie in der Apple-Dokumentation:

Ссылка