GCD Виды: 1. .main - главная очередь, тип - serial.

2. .custom - кастомная очередь, тип - serial или concurrent.
3. .global - системные очереди, тип - concurrent. Используется крайне редко в специфичных кейсах.


Типы:
1. Serial - последовательная очередь, имеет 1 поток.
2. Concurrent - параллельная очередь, имеет 1-64 потока.


Методы выполнения задач в serial и concurrent очередях:
1. .sync - синхронный - задачи выполняются друг за другом ожидая конца выполнения. Используется, когда важен порядок.
2. .async - асинхронный - задачи выполняются в параллельном потоке.

Добрый день. Сделал для себя шпору. Подскажите пожалуйста, все ли верно понял?

Последнее неверно. Sync/async, грубо говоря, влияет на то, будет ли ставящий в очередь код дожидаться поставленной в очередь задачи. Sync — будет, async — поставит и продолжит выполнение. Для порядка выполнения есть тип очереди

По отношению к вызывающей очереди

а про типы? serial может выполняться из разных потоков чи не? serial просто гарантирует выполнение задач по очерёдно про Concurrent на сколько я знаю цифра в 64 потока взята из предположений, эплы никогда не писали что у них ограничение на 64 потока

Неверное сформулировал, но главное что понял правильно. Я имел ввиду: Sync - работает «в паре» с другими очередями и дожидается выполнения задач по порядку Async - не дожидается. Тут скорее вопрос в том, правильно ли я понял concurrentQueue

Я бы на собесе докапался до «по порядку». Формулировка важна

Скорее да, чем нет. У Apple в документации такого не находил. Но в целом похоже на правду (тестировал циклом)

*открывает_форточку_мем.джипэг*

https://stackoverflow.com/questions/15150308/workaround-on-the-threads-limit-in-grand-central-dispatch

Что то этот текст меня еще больше запутал. Чем отличается ‘ставящий код’ - давай называть это клоужр, чем клоужр как код отличается от ‘поставленной в очередь задачи’ - что за ‘поставлення в очередь задача'? Разве клоужр закинутый на очередь не является этой самой задачей? Тобишь sync - это когда новый клоужр должен дождаться окончания работы прошлого клоужра?

Давай ещё шпоры какие у тебя есть

Очередь обслуживает задачи. Ок, условимся что задача = кложура. Мб так тебе проще, но я бы советовал думать абстрактно. Итак есть два вида очереди, с последовательным выполнение задач и параллельным. Какая это очередь определяется при создании очереди и изменить это поведение нельзя после. Создал serial - кложуры которые ты туда посавишь будут выполнятся одна за одной, в том порядка, в каком были добавлены в очередь. Неважно sync или async/ Задачи в очередь ствит какой-то код, который ты пишешь. Пусть у тебя будет фунция func makeThumbnail() { let source = getCurrentImage() // 1 var result: UIImage? // 2 someQueue.sync { result = source.resize() // 3 } someImageView.image = result // 4 } Вот тело это функции — код ставящий в очередь задачу. Видишь код? Что он делает? Он ставит в очередь задачу на ресайз. Конкретно в этом случае код код пойдет получит изобрадение (1), потом выделит память переменную (2) потом поставит задачу (3) в очередь и будет ждать пока она не исполнится. После чего запишет результат в имейдж вью. Что за очередь someQueue, serail или concurent неважно, важно что ставящий задачу в очередь код использует sync, то есть будет дожидаться выполнения кложуры. Примеры: - Допустим someQueue - serail очередь. В неё уже кто-то натолкал каких-то задач(кложур), пусть их будет 3. Наш makeThumbnail поставит еще одну, и будет ждать пока выполнятся 3 предидущие и интересующая его кложура. И продолжит своё выполнение только после этого. - Допустим someQueue - concurent очередь. В неё уже кто-то натолкал каких-то задач(кложур), пусть их будет 3. Наш makeThumbnail поставит еще одну. Т.к. очередь concurent предыдущие 3 будут выполнятся параллельно, наша новая задача (кложура) сразу же начнет выполнение, но мы все равно будем ждать пока она выполниться.

Небольшая ремарка, мало кто знает, но вызов sync у очереди в большинстве случаев не добавляет задачу в саму очередь, вернее сказать задача ожидает выполнение других задач в очереди, НО сама она выполняется на текущем потоке. sync ведь заставляет вызывающий поток ожидать, вот разработчики в целях оптимизации и подумали, что бы избежать переключение контекста, иногда лучше сделать вид что выполняешь задачу в очереди, на самом деле выполнить её на стороне вызывающего кода. Но спустя какое-то время, разработчики ядра улучшили свой планировщик, и с вызовом sync пошли проблемы, с одной стороны игнорируется qos очереди, так как выполняется не там, с другой переключение контекста стало не таким трудозатратным делом как раньше. Поэтому позже разработчики GCD добавили метод asyncAndWait. Он гарантирует, что задача выполнится внутри самой очереди и гарантирует что вы дождётесь на текущем потоке её выполнения. Итого вместо sync в 90% лучше использовать asyncAndWait. Не знаю кому это нужно будет, но вот как-то так 😅

найс дока кстати

Так это все хорошо, но где ты инфу черпаешь если не секрет? Или то надо сорсы курить и на опыте быть)))?

Ну вот теперь ты знаешь в какой спешке это добавили и зачем )

Я скину твит главного мейнтейнера GCD на эту тему если найду.