Пятничный деплой

Forwarded from Евгений Козлов пишет про IT (Eugene Kozlov)

CPU, Memory Models, Concurrency, Multiprocess, Multithreading и Async. Часть 11. Сравнение видов многозадачности

В прошлом посте было дано определение 2м основным видам многозадачности используемых в Computer Science. В этом посте хочется дать чуть больше пояснений и порассуждать где и почему они применяются.

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

Какие основные плюсы и минусы есть у данного подхода к мультизадачности:
- Плюс: невозможна ситуация когда ресуры системы голодают (starvation) в ожидании работы. Планировщик всегда найдет для процесса поток и ядро процессора для исполнения команд.
- Минус: наличие планировщика так или иначе дает оверхед.

Если переходить к кооперативности то тут основной плюс в том что переключениями может управлять разработчик (Ну или рантайм языка программирования, т.е нечто на уровне самой программы а не ядра ОС). И планировщика может и не быть вовсе. Но имея такую силу в своих руках можно получить ситуацию когда мы пишем кооперативный код который с легкостью заблокирует всю программу и не передаст возможность делать полезную работу дргим файберам в рамках процесса. По сути программа зависнет и придется ее перезапускать. Чуть менее критичная ситуация - starvation, когда файбер не передает ресурсы другим файберам хотя ему они сейчас не нужны (например он заблокировался на IO).

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

Для того чтобы программисты могли писать IO bound программы эффективнее разработчики языков и начали привносить в рантаймы различные легковесные примитивы. Но что произойдет в программе если мы сделаем блокирующий вызов (например запрос к БД)? Зависит от того как реализован рантайм конкретного языка программирования. Где то мы в ответ получаем Promise и продолжаем выполнение программы и заблочиться на нем в ожиданиии результата спустя время. В других языках реализованы специальные планировщики которые умеют детектировать файберы которые заблочились на IO и их можно безопасно снять с реального потока ОС и выделить время другим файберам. То есть по сути получаем некоторый микс из двух подходов, взяли лучшее из каждого.

А как быть с CPU Bound задачами? Никак, CPU задачи не масштабируются с помощью файберов. Чтобы разобраться почему приглашаю читать предыдущие посты с обсуждением процессора😊

На этом на сегодня всё, спасибо что читали, до встречи в следующих постах.😇

1.39K views15:54