Безопасность потоков и производительность адресной книги

Из документации по адресной книге и моего понимания базовой реализации CoreData можно предположить, что адресная книга должна быть потокобезопасной, а выполнение запросов из нескольких потоков не должно вызывать проблем. Но мне сложно найти в документации какое-либо явное обсуждение безопасности потоков. Это вызывает несколько вопросов:

  • Безопасно ли использовать + sharedAddressBook в нескольких потоках для доступа только для чтения? Я считаю, что да.
  • Для доступа на запись в фоновых потоках, похоже, вам следует использовать + addressBook (и сохранить изменения вручную). Я правильно понимаю?
  • Кто-нибудь исследовал влияние на производительность выполнения нескольких одновременных запросов к адресной книге в нескольких потоках? Это должно быть очень похоже на производительность выполнения нескольких запросов CoreData в нескольких потоках. Мне кажется, что я мало выиграю, выполняя параллельные запросы, поскольку я предполагаю, что они будут сериализованы при попадании в SQLLite, но я не уверен в этом.

Мне нужно сделать десятки запросов (некоторые сложные) к AddressBook, и я делаю это в фоновом потоке, используя NSOperation, чтобы избежать блокировки пользовательского интерфейса (что он сейчас и делает). Мой основной вопрос заключается в том, имеет ли смысл устанавливать максимальное количество одновременных операций на значение больше 1 и есть ли в этом какая-либо опасность, если приложение может одновременно писать в AddressBook в другом потоке.


person Rob Napier    schedule 16.07.2009    source источник
comment
То, что структура адресной книги в настоящее время (а это не всегда было так) использует Core Data, является деталью реализации, которую вы должны игнорировать, и не обязательно гарантирует потокобезопасность. Можете ли вы предоставить ссылку на документацию, в которой говорится, что API адресной книги является потокобезопасным? Мне не удалось найти политику потоковой передачи, указанную в документации.   -  person Jim Correia    schedule 16.07.2009
comment
Я тоже не могу его найти. Это то, о чем я говорил в первом абзаце. Я не могу найти явного обсуждения многопоточности с AB ни в одной документации. Но если предположить, что это не потокобезопасно, это создает большую сложность, которая вряд ли понадобится (и я не могу найти документацию о том, как правильно реализовать), что вызывает вопрос.   -  person Rob Napier    schedule 16.07.2009
comment
В отсутствие конкретной гарантии фреймворка или его части поточно-ориентированной, вы должны быть пессимистичны и предполагать, что это не так.   -  person Jim Correia    schedule 16.07.2009
comment
В частности, мы находим: Есть два способа получить копию адресной книги. Предпочтительный способ - использовать метод addressBook ABAddressBook. Объект адресной книги, который он возвращает, должен использоваться только в том же потоке, в котором он был создан, и может использоваться с методом ABPerson initWithAddressBook:., Четко заявляя, что AB НЕ является потокобезопасным.   -  person Tony Li    schedule 13.06.2012


Ответы (1)


Если API не говорит, что это потокобезопасный, это не так. Даже если текущая реализация является потокобезопасной, этого может не быть в будущем. Другими словами, не используйте AB из нескольких потоков.

Кстати, что насчет того, что он основан на CoreData, заставляет вас думать, что он будет потокобезопасным? CoreData использует модель ограничения потока, в которой безопасно обращаться к контексту только в одном потоке, все объекты из контекста должны быть доступны в одном потоке.

Это означает, что sharedAddressBook не будет потокобезопасным, если он поддерживает NSManagedObjectContext для использования. Было бы безопасно, только если AB создает новый контекст каждый раз, когда ему нужно что-то сделать, и немедленно избавляется от него, или если он создает контекст для каждого потока и всегда использует соответствующий контекст (возможно, сохраняя ссылку на него в threadDictionary) . В любом случае было бы небезопасно хранить что-либо как NSManagedObjects, поскольку контексты будут постоянно уничтожаться, а это означает, что каждый ABRecord должен будет хранить NSManagedObjectID, чтобы он мог восстанавливать объект в соответствующем контексте всякий раз, когда он в нем нуждался.

Ясно, что все это возможно, это может быть то, что делается, но вряд ли это очевидная реализация.

person Louis Gerbarg    schedule 17.07.2009
comment
Мне известно о проблемах потока / контекста с CoreData, поэтому я указываю на существование метода + addressBook. Если он не предоставляет отдельного контекста, какой цели он служит? (Конечно, другие задавали тот же вопрос, поскольку из документации неясно, чем отличаются + sharedAddressBook и + addressBook.) Отсутствие связи между потокобезопасностью, отсутствием механизма блокировки, отсутствием указаний относительно того, требуется ли mainThread, и чрезвычайно медленной работой, основной вопрос все еще не решен: как правильно писать приложения с высокой скоростью отклика, требующие много запросов AB. Время радара ... - person Rob Napier; 20.07.2009