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

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

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

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

В 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

Тесты — это отдельная тема для споров.

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

Считаю мощнейшим инструментом, который:
- Экономит время и деньги на ручное тестирование
- Дополнительно документирует код
- Ускоряют time-to-market
- Вся команда лучше заботится о качества

Вот еще крутейшая статья от @akaDuality

А еще мы ищем хорошего автотестера в нашу команду 💖 Если у вас есть такой, то пишите