#myTechNotes #concurrency #DeepDive

Note 2.

Поели немецких колбас, запивая темным пивом, и увидели что такое немецкое рождество. Подарили всем подарков, получили свои. Посомтрели "Один дома", так как немцы "Иронию судьбы не смотрят". А на следующий денб, так и вообще, выпал снег. Волшебно!

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

Я не до конца понимал как работают thread-ы (Потоки/треды). Раньше было понимание, что треды исполняются как то параллельно, что и дает нам ускорение вычислений. Но что меня смутило, так это то, что Треды у нас находятся внутри одного процесса, и выполняются на одном процессоре. А раз так, то откуда мы получаем ускорение, если процессор не может выполнять более одной инструкции в один момент времени.

Как оказалось, у устройства процессов, тредов, и корутин очень много общего. ОС постоянно бегает по всем процессам и постепенно продвигает их вперед. Все происходит настолько быстро, что человеческому глазу ничего не видно. Через какое то время умные люди придумали использовать треды, чтобы не переключаться между тяжелыми процессами. Переключение между тредами происходит намного быстрее, так как часть контекста они разделюят друг с другом, памяти выделяется меньше, и подмены переменных происходит меньше. Корутины - эта та же самая идея, когда Runtime проверяет в цикле доступность отдельных процедур, продвигая их вперед. Это еще более мелкая абстракция, которая работает внутри одного треда.

Откуда же приходит ускорение и в каких случаях?

Я в очередной раз убедился в том, что Concurrency works best with I/O bound tasks. Если при определенной процедуре CPU ничего не делает (is Idle), а просто простаивает (например, спит, ждет ответа от запроса к сайту, или ждет когда подгрузятся данные), то ничего полезного не происходит. Таким образом, мы можем "попросить" программу пойти дальше, чтобы исполнить что-нибудь другое в программе (другую корутину/тред).

С другой стороны, в случае же с CPU Bound tasks, наш процессор работает на всю мощность и переключаться между контекстами Корутин огромного преимущества не дает.

Вышесказанное это очень упращенная модель, чтобы не усложнять мое понимание. Фактически я понимаю, что простой может быть по различным причинам и не обязательно при IO. Преимуществ у использования Тредов больше чем просто при IO. Однако, я не могу представить, что в тех бэкэнд приложениях, над которыми я буду работать мне придется расматривать что-то более сложное.

Я уверен, что я еще буду возвращаться к этой теме в будущем, с performance tests и более сложными use-cases. Также хочу посравнивать concurrency модели в Golang, Python, и Kotlin. Но, на пока, более чем достаточно.

Если тебе тоже интересно почитать на эту тему и не хочешь тратить много времени на поиск полезных ресурсов, то рекомендую след:

Очень крутой, простой, и короткий курс на Coursera:
- https://www.coursera.org/learn/golang-concurrency

И статьи
- https://www.reddit.com/r/golang/comments/ddc1j3/what_is_the_point_of_concurrency/?sort=top
- https://eli.thegreenplace.net/2018/measuring-context-switching-and-memory-overheads-for-linux-threads/
- https://medium.com/@ankur_anand/illustrated-tales-of-go-runtime-scheduler-74809ef6d19b

__Если у тебя есть чем поделиться, дополнить, поправить, пиши, смело!__