https://khanlou.com/2016/04/the-GCD-handbook/
Multithreading in iOS| Difference between GCD and NSOperation
All about Concurrency in Swift - Part 1: The Present
Многопоточность (concurrency) в Swift 3. GCD и Dispatch Queues
https://tclementdev.com/posts/libdispatch_efficiency_tips.html
Ultimate Grand Central Dispatch tutorial in Swift - The.Swift.Dev.
Нужно сабклассить, переопределять Операции когда нужна отмена, и блоки хорошо можно разделить
GCD когда просто распараллелить, раскидать.
Семафор - понижает счетчик до 0 от заданного числа, блокирует блок кода Мьютекс - частный случай семафора (с цифрой 1), но чуть со своими прелестями. Мьютекс в своем потоке должен освободить, а семафор в любом может сигнал подать и разрешить продолжить. Бинарный семафор - альтернатива мьютексу.
https://gist.github.com/aainaj/a7ca2a98d0cd791566c46a7a7da5309dasync(flags: .barrier) чтобы убрать проблему чтения-записи. Пишем через асинк с барьером, читаем через sync. Глобальная конкаррент очередь.
Постоянный опрос, осмотр эвентов снаружи, таймеров и уведомление всех кто нужен. для таймеров нужно привязывать к ранлупу, или юзать scheduled отдельно. Run Loops глобальный скоуп и можно создавать локальные
Приоритет выбирается по режиму ранлупа. И чтобы при скролле таймер работал нужно использовать commonModes режим. Но только при необходимости.
Доклад про Runloop, Антон Сергеев
Ситуация, когда управление между потоками передаться не может, так как каждый поток ждет заблокирован, ожидая другой поток. И разрешения ситуации не происходит.
Как повторить: вызвать метод sync на main queue, и это приведет к взаимной блокировке (deadlock) приложения
Ситуация, когда каждый поток передает выполнение дальше в следующий поток, не делая на самом деле никакого действия.
https://swiftrocks.com/thread-safety-in-swift.html
Modern Concurrency in Swift: Introduction • Andy Ibanez
Доклад: Повседневные асинхронность и многопоточность / Александр Терентьев Доклад: Устройство многопоточности в iOS / Александр Андрюхин (Авито)
https://github.com/KosyanMedia/aviasales-ios/pull/11712 полезное чтиво от бывшего разработчика GCD: https://gist.github.com/tclementdev/6af616354912b0347cdf6db159c37057 свеженькое напоминание от перфоманс инженера из Apple: https://twitter.com/catfish_man/status/1516909101149671424?s=21&t=Ky8qqh1u_Ex1sc_DHpYNtw У меня еще есть примерно десяток ссылок про это, но короче, консенсус сегодняшнего дня в том, что использование конкурентных и глобальных очередей должно триггерить ревьювера) А как делать то? Вот : Just use a lock. Multi-reader single-writer synchronization always looks appealing, but it has a ton of subtle problems. Async writes sound appealing, but bringing up a thread is many orders of magnitude slower than setting a variable. Ок, локи, но какие? Будь мы на iOS 16+, ответ был бы прост — OSAllocatedUnfairLock . Это правильная свифтовая обертка над хитрым os_unfair_lock . os_unfair_lock просто так из Свифта не поиспользуешь, еще про хитрость Запомним OSAllocatedUnfairLock на будущее, а что пока? вот A serial queue or an NSLock is fine Это ответ на вопрос для тех, кто до iOS 16 еще не добрался) В целом, если снова говорить о консенсусе в коммьюнити, наш выбор состоит из: серийная очередь, своя корректная обертка над os_unfair_lock или NSLock. Акторы пока опускаем, не видел пока никаких рекомендаций по их использованию на низком уровне. Серийная очередь понятно, вероятно дороже чем локи. os_unfair_lock — ну можно хитрую обертку затащить , вероятно очень быстро получится, но что-то слишком много магии в заворачивании этого лока. NSLock — Eskimo пишет , что до iOS 16 нормально использовать NSLock, а обертки над os_unfair_lock скорее всего того не стоят. Итого: до iOS 16 я предлагаю использовать NSLock, а точнее обертку от poinftree (неожиданно?## 😀 ), над NSRecursiveLock. Рекурсивный медленнее обычного, но едва ли мы это заметим, зато поддержим какие-то сложные сценарии, что может быть актуально для библиотечной штуки. В поинтфришной обертке есть хитрые оптимизации, например __read, __modify ( про них ), если страшно, то можно убрать пока непонятные детали, но все же уйти от использования конкурентной очереди в пользу лока или хотя бы серийной очереди