@ d11wtq правильный ответ только при написании собственного кода или разработке собственных API .
Это совершенно неверно при работе с набором API и совершенно неверно при работе с Core Data.
В контексте работы с Mac OS X и iOS безопасность потоков всегда должна рассматриваться в контексте работы с системными API. Даже использование, скажем, NSArray означает, что вы работаете с системными API.
ИЛИ вообще что такое "не нить
сейф "?
Не поточно-безопасный API - это API, в котором вы не можете взаимодействовать с API из нескольких потоков одновременно. Также могут быть дополнительные ограничения, которые чаще всего связаны с основным потоком. Например, почти все операции рисования должны выполняться в главном потоке как в Mac OS X, так и в iOS.
В документации Apple предполагается, что безопасность потоков является исключительным случаем. Таким образом, API является поточно-ориентированным, только если документация явно заявляет о безопасности потоков . Если нет упоминания о безопасности потоков, вы должны предположить, что API не является потокобезопасным.
В Obj-C, что это значит в простом
термины; «CoreData не является потокобезопасным»
Это утверждение не совсем верно, но это безопасное предположение.
В случае Core Data поведение взаимодействия с потоками чрезвычайно хорошо задокументировано .
Короче говоря, части API являются поточно-ориентированными (например, координатор хранилища), а части явно не являются поточно-ориентированными. В то время как MOC предоставляет методы блокировки и разблокировки, вы можете также использовать внешнюю блокировку. Но не надо. Это будет менее эффективным и более хрупким; значительно так. В общем, не используйте внутреннюю блокировку. CoreData оптимизирован благодаря наличию контекста для потока / очереди.
(Ответ исправлен на основе отзывов TC. Спасибо.)