dispatch_queue_set_specific по сравнению с получением текущей очереди

Во-первых, я действительно не думаю, что вы хотели сделать эту очередь параллельной. dispatch_sync()ing в параллельную очередь на самом деле ничего не даст (параллельные очереди не гарантируют упорядочение между работающими в них блоками). Итак, остальная часть этого ответа предполагает, что вы имели в виду последовательную очередь. Кроме того, я собираюсь ответить на это в общих чертах, а не на ваши конкретные вопросы; надеюсь, это нормально :)

Есть две фундаментальные проблемы с использованием dispatch_get_current_queue() таким образом. Один очень общий, который можно резюмировать как «рекурсивная блокировка - плохая идея», и один, относящийся к диспетчеризации, который можно резюмировать как «вы можете и часто будете иметь более одной текущей очереди».

Проблема №1: рекурсивная блокировка — плохая идея

Обычной целью частной последовательной очереди является защита инварианта вашего кода ("инвариант" означает "что-то, что должно быть правдой"). Например, если вы используете очередь для защиты доступа к свойству, чтобы оно было потокобезопасным, то инвариантом является «это свойство не имеет недопустимого значения» (например: если свойство является структурой, то половина структура может иметь новое значение, а половина может иметь старое значение, если она устанавливается из двух потоков одновременно.Последовательная очередь заставляет один поток или другой закончить установку всей структуры до того, как другой сможет начаться).

Мы можем сделать вывод, что для того, чтобы это имело смысл, инвариант должен сохраняться при начале выполнения блока в последовательной очереди (иначе он явно не был защищен). Как только блок начал выполняться, он может сломать инвариант (скажем, установить свойство), не опасаясь испортить любые другие потоки, пока инвариант снова сохраняется к моменту его возврата (в этом примере свойство должно быть полностью задавать).

Подводя итог, просто чтобы убедиться, что вы все еще следуете: в начале и конце каждого блока в последовательной очереди должен сохраняться инвариант, который защищает очередь. В середине каждого блока он может быть сломан.

Если внутри блока вы вызываете что-то, что пытается использовать вещь, защищенную очередью, то вы меняете это простое правило на гораздо более сложное: вместо «в начале и в конце каждого блока» это « в начале, конце и в любой точке, где этот блок вызывает что-то вне себя". Другими словами, вместо того, чтобы думать о потокобезопасности на уровне блоков, теперь вам нужно проверять каждую отдельную строку каждого блока.

Какое это имеет отношение к dispatch_get_current_queue()? Единственная причина использовать здесь dispatch_get_current_queue() — это проверить «мы уже в этой очереди?», а если вы уже в текущей очереди, то вы уже находитесь в страшной ситуации, описанной выше! Так что не делай этого. Используйте частные очереди для защиты вещей и не вызывайте другой код изнутри них. Вы уже должны знать ответ на вопрос «Я в этой очереди?» а должно быть "нет".

Это основная причина, по которой dispatch_get_current_queue() устарел: чтобы люди не пытались имитировать с его помощью рекурсивную блокировку (то, что я описал выше).

Проблема №2: у вас может быть несколько текущих очередей!

Рассмотрим этот код:

dispatch_async(queueA, ^{
    dispatch_sync(queueB, ^{
        //what is the current queue here?
    });
});

Очевидно, что очередь B текущая, но мы все еще находимся в очереди A! dispatch_sync заставляет работу в очереди A ожидать завершения работы в очереди B, так что они оба фактически являются "текущими".

Это означает, что этот код заблокируется:

dispatch_async(queueA, ^{
    dispatch_sync(queueB, ^{
        dispatch_sync(queueA, ^{});
    });
});

Вы также можете иметь несколько текущих очередей, используя целевые очереди:

dispatch_set_target_queue(queueB, queueA);
dispatch_sync(queueB, ^{
    dispatch_sync(queueA, ^{ /* deadlock! */ });
});

Что действительно нужно здесь, так это что-то вроде гипотетического "dispatch_queue_is_synchronous_with_queue(queueA, queueB)", но поскольку это будет полезно только для реализации рекурсивной блокировки, а я уже описал, насколько это плохая идея... вряд ли это будет добавлено.

Обратите внимание, что если вы используете только dispatch_async(), вы невосприимчивы к взаимоблокировкам. К сожалению, вы вовсе не застрахованы от условий гонки.

Вопрос 1. Два фрагмента кода делают одно и то же, то есть "работают", когда блок действительно работает в firstQueue. Однако они используют разные способы определения того, что он работает на firstQueue, первый устанавливает не NULL контекст ((void*)myFirstQueue) с определенным ключом (myFirstQueue), а затем проверяет, что контекст действительно не NULL; вторая проверяет с помощью уже устаревшей функции dispatch_get_current_queue. Предпочтительнее первый способ. Но тогда мне это кажется излишним, dispatch_sync гарантирует запуск блока уже в firstQueue.

Вопрос 2: просто использовать static int * myFirstQueue = 0; нельзя, таким образом, myFirstQueue является указателем NULL, а dispatch_queue_set_specific(firstQueue, key, context, NULL); требует, чтобы для работы не использовались NULL key и context. Однако он будет работать с небольшими изменениями, такими как:

static void *myFirstQueue = 0;
dispatch_queue_t firstQueue = dispatch_queue_create("com.year.new.happy", DISPATCH_QUEUE_CONCURRENT);
dispatch_queue_set_specific(firstQueue, &myFirstQueue, &myFirstQueue, NULL);

это будет использовать адрес переменной myFirstQueue в качестве ключа и контекста.

If we do:

static void *myFirstQueue = 1; 
//or any other number other than 0, it would be OK to revert back to the following?
dispatch_queue_set_specific(firstQueue, myFirstQueue, (void*) myFirstQueue, NULL);

Я думаю, все будет хорошо, так как оба указателя myFirstQueue не будут разыменованы, если последний параметр destructor равен NULL

dispatch_once_t также 0 не имеет к этому никакого отношения. Сначала он равен 0, и после того, как он будет отправлен один раз, его значение изменится на ненулевое, по существу действуя как логическое значение.

Вот выдержки из once.h, вы можете видеть, что dispatch_once_t на самом деле является long и что детали реализации Apple требуют, чтобы оно было изначально 0, вероятно, потому, что статические и глобальные переменные по умолчанию равны нулю. И вы можете видеть, что есть строка:

if (DISPATCH_EXPECT(*predicate, ~0l) != ~0l) {

по существу проверка once predicate по-прежнему равна нулю перед вызовом функции dispatch_once. Это не связано с безопасностью памяти.

/*!
 * @typedef dispatch_once_t
 *
 * @abstract
 * A predicate for use with dispatch_once(). It must be initialized to zero.
 * Note: static and global variables default to zero.
 */
typedef long dispatch_once_t;

/*!
 * @function dispatch_once
 *
 * @abstract
 * Execute a block once and only once.
 *
 * @param predicate
 * A pointer to a dispatch_once_t that is used to test whether the block has
 * completed or not.
 *
 * @param block
 * The block to execute once.
 *
 * @discussion
 * Always call dispatch_once() before using or testing any variables that are
 * initialized by the block.
 */
#ifdef __BLOCKS__
__OSX_AVAILABLE_STARTING(__MAC_10_6,__IPHONE_4_0)
DISPATCH_EXPORT DISPATCH_NONNULL_ALL DISPATCH_NOTHROW
void
dispatch_once(dispatch_once_t *predicate, dispatch_block_t block);

DISPATCH_INLINE DISPATCH_ALWAYS_INLINE DISPATCH_NONNULL_ALL DISPATCH_NOTHROW
void
_dispatch_once(dispatch_once_t *predicate, dispatch_block_t block)
{
    if (DISPATCH_EXPECT(*predicate, ~0l) != ~0l) {
        dispatch_once(predicate, block);
    }
}
#undef dispatch_once
#define dispatch_once _dispatch_once
#endif

Вопрос 3: если myQueue является последовательной, параллельные очереди подходят.

dispatch_async(myQueue, ^{
    dispatch_sync(myQueue, ^{
        NSLog(@"This would be a deadlock");
    });
});

Вопрос 4. Не уверен.