Отдохнем немного от многопоточности.

В проектах начинающих разработчиков часто встречаю синглтоны. Есть много споров антипаттер ли одиночка или нет. Юзать его — ваша ответственность. Критично же юзать и не знать какие риски на себя берешь. Поэтому вкратце:

1. Синглтон нарушает SRP (Single Responsibility Principle) — класс синглтона, помимо того чтобы выполнять свои непосредственные обязанности, занимается еще и контролированием количества своих экземпляров.

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

3. Проблема тестирования. Вы не можете имитировать (mock away) синглтон при тестировании компонентов, использующих его. Это делает почти невозможным корректное модульное тестирование, потому что вы не добьётесь полной изоляции тестируемого кода.

есть неплохая статья, которая описывает все риски использования синглотона и его альтернативы

Современные операционные системы | Таненбаум Эндрю, Бос Херберт

Уровень воды: 40%

Оценка: 5/5

Супер жесткая книга, которую буду еще много раз перечитывать и возвращаться. Однажды на собесах заметил, что ограничиваясь только платформой и инструментами упускаю банальные вещи работы с многопоточкой или памятью в наших системах.

Эту книгу много раз советовали, но наше знакомство же состоялось с темой многопоточки. Здесь много полезнейших вещей (которые, если честно, не очень легко написаны)

Советую каждому. От новичков до опытных.

Хотел след пост о дедлоке запушить, но не смог не поделиться шедевральной статьей-переводом

Базовые принципы разработчика в гениальной простейшей форме

https://habr.com/ru/post/673640/

Почему DispatchQueue.sync приводит к deadlock?

Для начала разберемся кто это вообще такой ваш мертвый замок. Представим ситуацию в ресторане. Повар спрашивает повара официанта какой суп готовить, а официант отвечает, что скажет, только когда приготовишь суп.

Код выше обязательно придет к сбою. Очередь выполняет код синхронно. Второй клоужер не может запуститься, пока первый не закончится. Первый же клоужер не может выполниться, пока второй не запустится.

Проблема читателей-писаталей и барьер

Одна из самых частых задач на многопоточку. Чаще этой задачи на собесах никакую другую не повстречаешь. Почему? Потому что в любой статье или книге эту задачу каким-то боком да затрагивают.

Ее можно решить разными путями, но разберем самый подходящий.

Барьер — это механизм синхронизации потоков, который позволяет блокировать любое количество потоков до тех пор, пока ожидаемое количество потоков не достигнет барьера

В GCD есть свой механизм барьеров.

Барьеры GCD делают одну интересную вещь — они заставляют очередь временно не начинать новые задачи и ждут, пока все работающие в очереди задачи закончат свою работу, а затем выполняют свое замыкание.

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

Решение задачи читателей-писателей с помощью барьера

1️⃣ Мы создаем concurrent очередь*

2️⃣ Добавляем барьер на запись

3️⃣ Добавляем синхронный вызов на чтение

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

❌ Запомните, что global и serial очереди не лучший выбор для барьеров

1) Serial очередь ведет себя также, как и барьерная очередь. Поэтому особого импакта мы не заметим

2) С global очередями у нас меньше контроля и скорее всего мы не сможем синхронизовать данные

✅ Лучший вариант (единственно верный) это кастомные concurrent очереди

WatchDog — завершает работу задач, когда ОС убивает приложение за нарушение правил использования времени или ресурсов

- Синхронные запросы в сеть
- Обработка больших объемов данных, таких как большие файлы JSON или 3D-модели.
- Тяжеловесная обработка графики
- Приложение, превышающее лимиты фоновых задач
- Приложение использует слишком много ресурсов ЦП, что приводит к перегреву устройства.

Таски, завершенные ватчдогом имеют ошибку 0x8badf00d («съел плохую еду»)

Хороший разбор про производительность всяких мутексов и других блокировок:

https://swiftrocks.com/thread-safety-in-swift

Dispatch Group

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

✅ Для таких кейсов поможет Dispatch Group.
Он состоит из четырех основных методов:
1. enter(): вызывая enter, мы сообщаем DispatchGroup, что асинхронная задача началась.
2. leave(): означает, что асинхронная задача завершена.
3. notify(): уведомляет требуемый поток о том, что задачи в группе завершены.
4. wait(): блокирует текущий поток до тех пор, пока все задачи в группе не будут завершены

Swift Concurrency

Почти все примеры выше были с GCD. Часы пробили. Делаем разбор на Swift Concurrency

Новая модель concurrency тесно связана с языком. Она абстрагирует такие понятия как потоки. Но ее долгожданная фича – это async/await синтаксис

Подробнее можно познакомиться у покойного ситимобила, но и тут детально все разберем

Ментальные модели для итшника

Программист — это не только технарь. Давно уже нет. Программистом не станешь изучив доку очередного инструмента, или кишки компьютерных наук.

Программист должен обладать особым складом ума. Иметь культуру и повадки, присущие нашей индустрии.

Буду переодически кидать сюда интересные модели, которые, как мне кажется, должны быть в идеальном портрете программиста.

Вы можете с ними не согласиться, что нормально.

https://shopify.engineering/building-mental-models

Очень простой сборник. Для новичков идеально. Лучше всегда такое держать под рукой. Иногда рефрешить знания

https://tproger.ru/articles/sobesedovanie-ios-razrabotchika-voprosy-i-zadanija/

Хорошая статья по решению проблем читателей писателей с опять же замером производительности всяких мутексов

Как можем заметить NSLock в большинстве кейсах в разы (!) медленнее при записи и при чтении, чем барьер GCD и POSIX тредов

https://dmytro-anokhin.medium.com/concurrency-in-swift-reader-writer-lock-4f255ae73422

Изменения в структуре

Обычно такой текст пишут когда набирают красивую цифру подписчиков. Благодарят всех, пишут о ценности каждого. Но я напишу сейчас. Посмотрю в гугле какой там сегодня рандомный праздник и скажу, что в честь него. Как алкаш, который ищет повод, чтобы бахнуть очередную.

В сентябре прошлого года этот канал был создан как сборщик материалов. Тогда я был преподом в одной онлайн школе у 10 человек. Потом я написал пару статей и вот нас уже чуть больше 400.

Пора усиляться. Дальнейшие планы такие:

1️⃣ Добавить ранжирование контента на грейды. К каждой записи прекреплять тэг на какой уровень та или иная статья подходит.

2️⃣ Больше авторского контента. Делать библиотекой чужих статей ради вашего внимания и паразитировать на чужой работе особой мотивации нет. Буду выделять крутые статьи, или юзать как вводные, но приоритетней все же мутить свое:
- Разбор известных/инструментов либ и задачи их применения
- Марафоны по темам как с многопоточкой. Возможны сразу несколько марафонов в нескольких потоках (впереди UI и анимации, проектирование и много чего)

3️⃣ Возможно, как нас станет еще чуть больше, то будем делать закрытые чаты и создавать недельные интенсивы с домашним заданием и онлайн проверкой.

4️⃣ Мб в далекой перспективе усиление контентологов и создание какого-то свое микро-комьюнити, где важно качество, а не кол-во

5️⃣ Думаю о редизайне. Пздц конечно говорю будто это сайт и у меня какой-то бренд бук свой, но подумать об удобном формате материала и слоге стоит

С рандомным праздником Вас всех! Ценю, люблю.

Swift Concurrency Manifest

🟡 lvl: mid+

Отличный материал понять корни Swift Concurrency. С крутыми рефами и разборами проблем. Интересно почитать куда разрабы копали и где искали рефернсы, искали обоснования сложностям новых языковым конструкций.

Виден путь сделать язык не только популярным инструментом для мобильных разработок, но и взять рубежи на серверные проблемы

https://gist.github.com/lattner/31ed37682ef1576b16bca1432ea9f782

#lvl_mid