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?
    });
});

Ясно е, че queueB е актуален, но също така все още сме на queueA! dispatch_sync кара работата по queueA да чака завършването на работата по queueB, така че и двете са ефективно "актуални".

Това означава, че този код ще блокира:

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: Не съм сигурен.