Вытесняющая vs кооперативная многозадачность

если бы развитие пошло по пути кооперативной многозадачности?

в общем случае точно не пошло бы

Было бы лучше или хуже? Почему пошли по пути вытесняющей? Замешана ли тут политика, идеология?

см. плюсы и минусы двух подходов. Яндексится на раз, в той же википедии.

На фоне 10-летнего кризиса IT

какого кризиса?

Это в частности касается конкуреyции между линейками windows 9x и NT. 9x использовали кооперативную многозадачность

мда, молодежь даже про Windows 9х не знает… Windows 9x использовали кооперативную многозадачность только для 16-битных приложений. 32-битные выполнялись в вытесняющем режиме.

9x использовали частично кооперативную

ха! исправил таки :)

На фоне 10-летнего кризиса IT эти вопросы снова стали актуальными

windows 9x и NT

Где ты такую тухлую методичку откопал?

почему в общем случае не пошло бы?

какого кризиса?

Ну все ж знают что IT не просто стоит а деградирует на глазах.

У меня на ноуте в 00-х стоял автокад, полная линейка Adobe и все летало на 2-х гигах памяти. Опера была настолько быстрой, что ты не замечал переход по сайтам, как будто это были текстовые файлы на компе. Офис в 90-х специально замедляли для солидности. В мш ты не смог бы заметить отрисовки текста при любой скорости печати, он был как молния. Это все на допотопном железе с минимумом памяти.

мш=vi имелось в виду. А был еще TECO И вообще был настоящий UNIX от Bell Labs, который не какой то там гну

async в большинстве языков является реализацией кооперативной многозадачности в одном потоке.

почему в общем случае не пошло бы?

ты уже прочитал страничку в энциклопедии?

У меня на ноуте в 00-х стоял автокад, полная линейка Adobe и все летало на 2-х гигах памяти

Это все на допотопном железе с минимумом памяти.

Автокад это что-то такое супер ресурсоемкое? В 2000х 3D Max Studio как рендерил сложные сцены долго, так и сейчас рендеринг по-современному сложных сцен очень ресурсозатратен, и никаких «с минимумом памяти» тут не может быть. Включи мозг.

Да, там написано «поскольку она[кооперативная] использует более передовые методы, чем простое переключение задач»

Да, там написано «поскольку она[кооперативная] использует более передовые методы, чем простое переключение задач»

ссылку можно? Может я что-то не то читаю.

Я предпочитаю верить своим глазам. Сейчас гребаный хром стал «более ресурсоемким» чем те видеоредакоры

https://ru.wikipedia.org/wiki/%D0%9C%D0%BD%D0%BE%D0%B3%D0%BE%D0%B7%D0%B0%D0%B4%D0%B0%D1%87%D0%BD%D0%BE%D1%81%D1%82%D1%8C#%D0%A1%D0%BE%D0%B2%D0%BC%D0%B5%D1%81%D1%82%D0%BD%D0%B0%D1%8F_%D0%B8%D0%BB%D0%B8_%D0%BA%D0%BE%D0%BE%D0%BF%D0%B5%D1%80%D0%B0%D1%82%D0%B8%D0%B2%D0%BD%D0%B0%D1%8F_%D0%BC%D0%BD%D0%BE%D0%B3%D0%BE%D0%B7%D0%B0%D0%B4%D0%B0%D1%87%D0%BD%D0%BE%D1%81%D1%82%D1%8C

Я предпочитаю верить своим глазам.

«если лично я не видел, то этого не существует»?

Там через один абзац про недостатки написано. Это ответ на твой вопрос, почему в общем случае это плохое решение.

там далеко смотреть не надо. Даже «продвинутая» XP была 1 гиг.Монстры пошли как раз с Висты. Виста была в несколько раз больше и в несколько раз хуже.

я не понял что там написано, какой то бессвязный набор слов

В мш ты не смог бы заметить отрисовки текста при любой скорости печати, он был как молния.

я и на новых системах не замечаю

развитие пошло по пути кооперативной многозадачности? Было бы лучше или хуже?

Кооперативная на уровне ОС невозможна. Она просто не потянет все юзкейсы.

ты уникум походу

были ОС с кооперативной многозадачностью

тогда забей

ну так :)

Ну давай разберем по пунктам.

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

Это откуда ванек взял?

Они и сейчас есть для каких-нибудь микроконтроллеров. Чтобы мигать лампочкой и считывать показания АЦП этого достаточно. Чтобы поддерживать функциональность современной ОС - нет.

Я думаю что это общие слова без конкретного содержания, типа «у человечества нет иного пути кроме как путь к социализму!» бурные аплодисменты

объективно это можно так рассудить: поставь современное ПО на то железо на котором работало это ПО в 90-00х и все станет ясно

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

Это примитивные рассуждения. Можно сделать реализацию контроля за зависшитми приложениями не ломая при этом кооперативность.

Кстати по факту это не решается и в вытесняющей. Частенько приходится делать перезагрузку из-за зависшего приложения

Не шлангуй.

Производительность: в кооперативной многозадачности программист сам определят место в программе где может произойти смена контекста. Если выберет плохое место или редко будет отдавать контекст, то программа и ОС в целом будут плохо отзывчивыми. Если будет отдавать контекст часто, то будет неэффективная работа из-за лишних действий.

Безопасность: вредитель или просто криворукий программист может сделать так, что программа никогда не отдаст контекст. Так можно всю ОС повесить. Это явная уязвимость.

Облако: как предлагаешь запускать несколько виртуалок (vps) на одной железке? А если я куплю vps и сделаю там бесконечный цикл без смены контекста? Моя виртуалка повиснет и повиснет ядро сервера, которое обслуживало виртуалку в данный момент. Чё, двумя строчками кода повесил инфраструктуру облачного провайдера?

Функциональность: сделай мне аналог отладчика gdb в режиме кооперативной многозадачности. Вот я запустил программу под отладчиком и хочу её приостановить в произвольном месте, а не в точке смены контекста. Как мне это сделать? Отладчик будет висеть без процессорного времени пока программа не отдаст контекст. Или в таких случаях ты предлагаешь использовать исключительно многоядерные процессоры, чтобы отладчик и программа работали на разных ядрах?

Тысячи примеров…

Можно сделать реализацию контроля за зависшитми приложениями

То есть проблемы кооперативной многозадачности решаются путём добавления механизма… мм… вытеснения задач?

контроля

Вот одна из причин:

«Поэтому разработчики приложений для non-preemptive операционной среды, возлагая на себя функции планировщика, должны создавать приложения так, чтобы они выполняли свои задачи небольшими частями. Например, программа форматирования может отформатировать одну дорожку дискеты и вернуть управление системе. После выполнения других задач система возвратит управление программе форматирования, чтобы та отформатировала следующую дорожку. Подобный метод разделения времени между задачами работает, но он существенно затрудняет разработку программ и предъявляет повышенные требования к квалификации программиста»

То есть это мешает притоку в индустрию малоквалифицированного персонала

А вот преимущества:

"Однако распределение функций планировщика между системой и приложениями не всегда является недостатком, а при определенных условиях может быть и преимуществом, потому что дает возможность разработчику приложений самому проектировать алгоритм планирования, наиболее подходящий для данного фиксированного набора задач. Так как разработчик сам определяет в программе момент времени отдачи управления, то при этом исключаются нерациональные прерывания программ в «неудобные» для них моменты времени. Кроме того, легко разрешаются проблемы совместного использования данных: задача во время каждой итерации использует их монопольно и уверена, что на протяжении этого периода никто другой не изменит эти данные. Существенным преимуществом non-preemptive систем является более высокая скорость переключения с задачи на задачу. Примером эффективного использования невытесняющей многозадачности является файл-сервер NetWare, в котором, в значительной степени благодаря этому, достигнута высокая скорость выполнения файловых операций. Менее удачным оказалось использование невытесняющей многозадачности в операционной среде Windows 3.х. "

http://ermak.cs.nstu.ru/mos1/chap_3_3.php

Частенько приходится делать перезагрузку из-за зависшего приложения

Это либо 12309, либо зависание в драйвере (чаще всего видеокарты), а драйвера как раз работают в кооперативной многозадачности.

А почему там используют кооперативную?

Потому что сбой в пространстве ядра в любом случае всё угробит. Плюс ядро разрабатывается одной командой с общими стандартами качества и кодирования (в Linux Линус жёстко фильтрует патчи, в Windows с каких-то пор требуется сертификация от MS с цифровой подписью). При этом драйверам часто нужен риалтайм (так как работа с железом, например, может быть важно после записи в один регистр девайса прямо следующей командой записать в другой, а не уйти внезапно на исполнение другой задачи), в то время как для пространства пользователя лаг в несколько миллисекунд почти всегда некритичен.

Кооперативная многозадачность может иметь меньше накладных расходов и работать быстрее на embedded устройствах. На сохранение/загрузку регистров при вытесняющей многозадачности тратятся дополнительные ресурсы.

На сохранение/загрузку регистров при вытесняющей многозадачности тратятся дополнительные ресурсы.

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

при кооперативной регистры тоже спасаются.

Во первых не все регистры, а во вторых не обязательно и зависит от реализации. Бывает кооперативная многозадачность основанная на колбеках когда единицей исполнения является функция-колбек которая выполняется в течении небольшого времени.

на колбеках - это вообще не многозадачность. там даже стек не надо переключать. на колбеках делать вообще не следует.

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

на колбеках - это вообще не многозадачность.

Почему? Если грамотно вручную разбить задачи на функции с коротким временем исполнения то вполне себе будет многозадачность. Частным случаем такой многозадачности является GUI с главным циклом обработки сообщений и функциями-колбеками обработки сообщений. Ещё многие компьютерные игры основаны на колбеках.

если переключается стек и есть оптимизация все равно спасать надо все регистры

Нет, сохранять надо только preserved регистры. Функция переключения вроде Yield() имеет право портить non-preserved регистры.

…Если грамотно вручную

как много их, упало в эту бездну…

Ядро, насколько я знаю, вытесняемое, начиная с версии 2.6.
А в NT с самого начала.

так там заявляется что вытесняющая многозадачность и есть риалтайм. Тут что конкретно имеется в виду?

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

Хотя на уровне ОС там видимо все равно этот поток прерывается, но это абстрагированно. Модель выполнения там именно такая.

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

давайте задачи отдельно, а «асинхронность» - отдельно.

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

от того как переключается задача - самой задачей или внешней активностью - шедулером и появляются два вида многозадачности - кооперативная и «вытесняющая».

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

Потому что MacOS Classic уже была.

не надо ничего отдельно, суть там та же самая. Функция - это по сути программа которая выполняется за один раз(не считая всяких там ручных передач управления типа call/cc и сопрограмм).

и почему не пошла?