Подтвердить что ты не робот

@synchronized против GCD dispatch_barrier_async

Я начал контролировать очереди в первый раз и чувствую, что у меня есть хорошая ручка о том, как использовать их и прикосновение к Apple, чтобы сделать их довольно простыми в использовании.

Однако я столкнулся с проблемой чтения и записи нескольких потоков на одни и те же объекты. В этом вопросе я получил этот прекрасный ответ, и он оставляет меня с просьбой дать какое-то подтверждение от всех, чтобы убедиться Я понимаю плюсы и минусы @synchronized vs GCD dispatch_barrier_async.

Вот так я вижу:

 @synchronized

PRO. Вы можете обернуть любой объект в @synchronized до тех пор, пока у вас есть доступ/указатель на него, что упрощает безопасное обращение к моделям общих данных с разных объектов в программе

PRO: поддерживается iOS 4 (и, возможно, раньше)

 `dispatch_barrier_async` with custom DISPATCH_QUEUE_CONCURRENT

PRO: быстрее, чем @synchronized

CON: DISPATCH_QUEUE_CONCURRENT доступен только в iOS 5 (как обсуждалось здесь), поэтому недоступно для поддержки iOS 4

CON: не так просто использовать при управлении чтением/записью объекта из многих других объектов, поскольку очереди наиболее легко доступны только для объекта, который их создает (без какой-либо работы это ограничение)

В общем, лучший инструмент зависит от потребностей программы, учитывая вышеизложенное.

Если у кого-то есть что добавить или указать, я был бы признателен.

4b9b3361

ОТВЕТЫ

Ответ 1

Ну, несколько вещей, чтобы указать:

1) Когда вы используете @synchronized, он извлекает фрейм для исключений WHOLE для iOS (или OSX) для приложения. Я знаю об этом на OSX, и он имеет влияние на производительность там, не могу сказать наверняка на iOS, но ожидал бы того же. Тем не менее, это использование кувалды для вождения в гвоздь - эта возможность была вокруг, прежде чем были доступны другие варианты. Я лично избегаю его использования, как чума, и портировал другие рамки с открытым исходным кодом для использования семафоров отправки (я благодарю Майка Эша (снова) за это!)

2) Ваш комментарий о "DISPATCH_QUEUE_CONCURRENT" - это красная селедка рода - с iOS 4 система предоставила вам 3 параллельные очереди, поэтому вы действительно нажимаете конверт, если вам нужно определить свой собственный. При отправке у вас есть асинхронные и синхронизирующие, последовательные и параллельные группы, на которые вы можете дождаться, после отправки. Здесь есть такое богатство, как вы могли даже думать об 1). Чем больше вы используете блоки, тем больше вы их будете использовать!

EDIT: Я использовал пользовательские параллельные очереди в моем приложении iOS 4.3 вместе со всеми методами барьера Майка Эша. Файл queue.h показывает его как доступный:

__OSX_AVAILABLE_STARTING(__MAC_10_6,__IPHONE_4_0)
DISPATCH_EXPORT DISPATCH_CONST DISPATCH_WARN_RESULT DISPATCH_NOTHROW
dispatch_queue_t
dispatch_get_global_queue(dispatch_queue_priority_t priority, unsigned long flags);

/*!
 * @const DISPATCH_QUEUE_SERIAL
 * @discussion A dispatch queue that invokes blocks serially in FIFO order.
 */
#define DISPATCH_QUEUE_SERIAL NULL

/*!
 * @const DISPATCH_QUEUE_CONCURRENT
 * @discussion A dispatch queue that may invoke blocks concurrently and supports
 * barrier blocks submitted with the dispatch barrier API.
 */
#define DISPATCH_QUEUE_CONCURRENT (&_dispatch_queue_attr_concurrent)