Хабр Курсы для бэкендеров
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Бэкенд доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 25
А вытесняющая многозадачность точно связана с нитями? Странное какое то утверждение, имхо
Да, связана. Формально, это механизм, который переключает исполняемые задачи беспрекословно, по своему усмотрению. Этот термин используется в контексте операционных систем, где многозадачность реализуется через управление нитями.
Вы от частного (один и тот же task_struct, хотя и отличающийся для процессов и потоков) переходите к общему. И потом что, если в ос нет "нитей", она не может быть с вытесняющей многозадачностью? Возьмите freertos, к примеру - там есть задачи/таски, но нет процессов и нитей, и есть вытесняющая многозадачность
В статье определённо хватает вольностей. Но на всякий случай ещё раз перечитал места, где упоминается вытесняющая многозадачность. Я говорил, что механизм переключение нитей относится к этой стратегии. И не утверждал, что прямо-таки все операционные системы работают на нитях. Наверняка есть и такие, где вытесняющая многозадачность реализуется посредством других абстракций, но никто про них не знает)))
Точнее, вот сейчас узнал про freertos, но всё ещё не вижу веских причин для правок статьи.
Ну а вот я первый раз узнал из статьи, что вытесняющая, как и кооперативная многозадачности как понятия вообще связаны с нитями)
Прошу прощения, если ввёл в заблуждение)) Нити можно считать абстракцией над запущенными задачами. Их реализация меняется от одной ОС к другой. Наверняка есть ОС, где такая абстракция радикально отличается от большинства других и заслуживает отдельного названия. Но суть термина "многозадачность" не меняется - это механизм исполнения множества задач на ограниченном вычислителе, путём их регулярного переключения. Просто так уж сложилось в большинстве популярных ОС такое переключение реализовано через абстракцию, называемую thread))
Формально не связана, но фактически во всех современных ОС единицей планирования для вытесняющей многозадачности является нить. То есть связь тут прагматическая.
Хороший обзор, спасибо
Классная статья, но бывает не очень понимаю смысла перевода некоторых слов типа "эффективный (effectful)", как будто перевод ради перевода
Спасибо! Я хотел подчеркнуть, что термин "эффективный шаг" подразумевает, что он "несёт (побочный) эффект", но не в том смысле, что он "оптимален" или ещё что. В англоязычной литературе для этих целей употребляют слово "effectful". Вообще многочисленные переводы в этой статьей - это мой маленький протест против укоренившихся в IT ангицизмов и даже рунгиша)). Поэтому часто использую именно переведённые термины сопоставляя их с англоязычными.
Так как мы хотим выжать максимум из используемого оборудования, нужно минимизировать время простоя процессора, загрузить его полезной работой.
Вы же вот статью эту на компьютере писали, так ведь? И во время этого писания у вас тоже цель была "выжать максимум из используемого оборудования", или все таки вы пытались написать хорошую статью?
Я вот почему то не верю, что вы самозабвенно стучали по клавишам лишь бы не дать компьютеру простоя.
Насколько я знаю цель многозадачности и многопоточности сделать программу/операционную систему отзывчивой в первую очередь, чтобы пока система занята какой-то тяжелой задачей (компиляцией например, декодированием видео, просто копированием файлов, ...) можно было например Хабр открыть-почитать в это время, причем, даже на совсем одноядерной машине.
сделать программу/операционную систему отзывчивой в первую очередь
Система и так дюже отзывчивая, особенно если с LLM общаться))
Она перестаёт быть отзывчивой лишь под нагрузкой, когда процессор занят какой-то фигнёй вместо того чтобы Хабр отрисовывать. Этой фигнёй может быть бессмысленное переключение нитей в режиме пробуксовки, но чаще (если с этим не бороться) - это просто пустое ожидание внешнего сигнала. Вот такой "простой" и надо минимизировать, загружая его мало-мальски полезной задачей. Многозадачность - это способ повышения полезности вычислительной мощности компьютера как раз с помощью попытки минимизировать бесполезные "простои" и "ожидания" путём переключения на одну из множества (возможно) более полезных задач.
Прошу прощения. Устал вечером и не уловил ваш посыл. А предыдущий свой ответ уже не удалить..
Действительно, многозадачность частично решает проблему неэффективного использования вычислительных ресурсов, но более важная цель - справедливое их распределение между задачами. Чтобы ни какая задача не смогла забрать заблокировать ресурс и "подвесить" прочие задачи.
Спасибо за замечание! Утром придумаю, как исправить текст.
Это две разные стратегии планирования. Правда в том, что максимизация пропускной способности как стратегия планирования применялась в основном в пакетных операционных системах на заре вычислительной техники, хотя и сейчас бывает актуальна для суперкомпьютеров, мейнфреймов и прочего big iron.
а в чем? разница:
когда вы сидите за десктопом с графическим-визуальным интерфейсом, вы хотите чтобы у вас файлы открывались, скролировались, ... не зависимо от того какой тяжелый софт выполняется параллельно;
когда вы подключаетесь к серверу (суперкомпьютер-у, мейнфрейм-у и прочего big iron) по ССЧ вы хотите чтобы он отвечал вам в этом терминале не зависимо от того сколько миллионов запросов он при этом обрабатывает, какую супер-задачу он при этом просчитывает и сколько других ССЧ сессий к нему уже подключено параллельно.
Суть в том, что сколько бы не было потоков-процессов-задач в системе, и как бы они не были тяжело ЦПУ-баунд, у операционной системы должна быть возможность их все(!) подвинуть чтобы втиснуть еще одну задачу-процесс-сессию, чтобы в этой сессии тоже было видно прогресс выполнения со стороны пользователя.
В радиотехнике есть такое понятие "скважность". Операционная система фактически управляет скважностью присутствия задач-процессов в обработке на реальных ядрах-процессорах. Это изменение скважности до некоторого предела вообще никак пользователю не видны, так как мы не в состоянии отличить 10 милли секунд от 15 милли секунд например, для нас это одинаково мгновенно, хотя разница в полтора раза.
Разница в том, что время суперкомпьютера стоит дорого, и обычно выгоднее подождать, пока он не спеша всё посчитает, чем заплатить вдвое за обслуживание приоритетных сессий.
Переключение между процессами – довольно дорогая операция сама по себе, а если это сопряжено, например, со свопингом, то очень дорогая.
Разница в том, что время суперкомпьютера стоит дорого, и обычно выгоднее подождать
так при том что время суперкомпьютера стоит дорого, ССЧ сессия (для примера) отнимает гораздо меньше процент ресурсов чем на обычном сервере и добавленные для этой сессии переключения контекста (на самом деле, почему нужно обязательно Переключение между процессами не совсем понятно) можно тоже минимизировать!
В общем аргумент понятный, но насколько, практически, этот аргумент работает и работает ли по техническим параметрам, надо смотреть внимательно в каждом конкретном случае.
я бы вообще не стал приплетать в эту дискуссию суперкомпьютеры. Каждый суперкомпьютер - это всегда очень специальный случай. Я бы ограничился типами серверы-десктопы.
Внёс несколько правок, касающихся многозадачности.
Ещё раз спасибо за обратную связь.
Проблема с чисто-библиотечными реализациями кооперативной многозадачности в том, что любая блокирующая операция в таске, тот же sleep() или блокирующее чтение на сокете, и всё: реальный поток из пула будет заблокирован, он не будет тратить CPU, но и таски выполнять он не будет. Поэтому в помощь такой реализации нужен IO manager, который или будет в своём потоке делать select() на сокетах, или будет использовать асинхронные сокеты операционки. Это означает, что граница разделения тасок будет проходить по таким операциям, и разработчик должен хорошо это понимать.
Нити и волокна (Threads & Fibers)
Thread в русской терминологии - это всё-таки "поток".
Если сохранять исходный посыл, что "нить" состоит из "волокон", то "fiber" - это "струя".
Исходный посыл - это именно "thread", то есть нить, потому что "тянется". Тут дело в том, "поток" - это "stream", термин, обозначающий другое понятие во многих средах разработки. Просто на моей практике частенько встречал путаницу из-за неоднозначности трактовки слова "поток".
Мне кажется, что перевод "thread" как "поток" не очень удачен. Да, так уже вроде как устоялось... Но всё же я не одинок - в некоторых источниках также встречал слова "нить". Ничего не вижу в этом плохого))
Мы же помним в какой компании придумали Unix. Терминология многозадачности исторически вдохновляется телекомами, которые соединяли абонентов проводами и занимались обработкой сигналов. Один провод - один сигнал. Несколько проводов параллельно и вот мы можем обслуживать сразу несколько абонентов. Из этого кабельного хозяйства в архитектуре операционных систем и компьютеров позаимствована масса метафор. По-хорошему, core, thread, fiber и т.п. нужно представлять себе именно в этом контексте. Thread это проводник. Fiber - жилка, из которых они могут состоять, как что-то более лёгкое.
В области передачи данных принято использовать аналогии из сантехники. Там трубы pipe, потоки stream, муфты socket и т.п.
При адаптации на русский этот нюанс потеряли, превратив thread в "поток", а нитки воспринимаются как вообще что-то из лёгкой промышленности (хотя если копать дальше, то понятия из мира электрических проводов про нитки и волокна происходит как раз отсюда). Понятно, что в голове такое не укладывается.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Нити и волокна (Threads & Fibers)