Многозадачность

[SfS]

Многозадачность НУЖНА однозначно. Иначе это будет не ОС, а какойто СуперКоммандер для запуска игрушек. А так можно скажем запустить игрушку и другую задачу, которая будет, скажем, отладчиком. Игрушка играется, отладчик в фоне чтото отслеживает. Или скажем читать текст и слушать музон в МП3 (если конечно аппаратный декодер прикрутить). Да мало ли ? ОС 21го века не должна быть однозадачной )

[Alex/AT]

а ты знаешь что это уже давным-давно реализовано в "настоящих" ОС? %)
это функции sleep, alarm, wait (UNIX), sleep, yield (win). и никаких проблем нету

То же самое сделано в RTK. Единственное отличие - это то, что "в настоящих ОС" требуется аппаратная поддержка переключения контекста. У нас этого нет.

[elf/2]

Давай. Дай определение потоков и задач в моих интрах, учитывая отсутствие MMU

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

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

[lvd]

Единственное отличие - это то, что "в настоящих ОС" требуется аппаратная поддержка переключения контекста. У нас этого нет.

А что значит 'аппаратная поддержка переключения контекста'? Вон, в 68k и даже powerpc такого нет, но оси себя чувствуют отлично, в том числе и линухообразные! =)

[lvd]

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

Естественно заточенным под задачу (двузадачным даже), но а вот в амигаос тоже заточенным под задачу рулится (т.е. менеджером именно для амигаОС) и тоже память общая. Во многих вытесняющих РТОС тоже память общая. И что же - теперь все они всего лишь навсего многопоточные? Я и говорю - не надо с мерками линуха подходить ко всему. Линух - далеко не эталон. А кругозор полезно расширять хоть иногда. =)

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

Каким образом и почему имеет смысл? Задача = указатель PC + стек + состояние остальных регистров + некая инфа для свичера (приоритеты и т.д.), чем это от потока отличается??

Про бритву Оккама что ли напомнить? Или не надо? =)

[elf/2]

Каким образом и почему имеет смысл? Задача = указатель PC + стек + состояние остальных регистров + некая инфа для свичера (приоритеты и т.д.), чем это от потока отличается??

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

[Advertiser]

[lvd]

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

В линухе и в винде блоки памяти никто не сохраняет при переключении контекста (своп пока не рассматриваем). Просто переключают таблицы ММУ - если у каждого процесса своя виртуальная память.

В осях без защиты памяти опять же никто блоки памяти не копирует - все просто живут в общей памяти. Я ещё не встречал ни одной оси без защиты памяти, где при переключении контекста КОПИРУЕТСЯ вся память процесса. Такие вообще существуют? =) Подозреваю, что нет, но даже если и существуют, то это не означает, что такое же извращение надо на спеке делать.

[elf/2]

В линухе и в винде блоки памяти никто не сохраняет при переключении контекста (своп пока не рассматриваем). Просто переключают таблицы ММУ - если у каждого процесса своя виртуальная память.

В осях без защиты памяти опять же никто блоки памяти не копирует - все просто живут в общей памяти. Я ещё не встречал ни одной оси без защиты памяти, где при переключении контекста КОПИРУЕТСЯ вся память процесса. Такие вообще существуют? =) Подозреваю, что нет, но даже если и существуют, то это не означает, что такое же извращение надо на спеке делать.

а кто здесь обсуждает линух или винду да еще с MMU?

само собой _ВСЮ_ память процесса никто копировать никуда не будет. но, согласно некоторым сообщениям в соседних ветках:
1. код процесса живет в странице -> переключаемся на новую
2. часть выделенной памяти живет в куче (ниже #c000) поэтому если новому процессу надо много памяти в куче, то надо спрятать RW блоки текущего процесса и вернуть/выделить блоки для нового.

само собой такой изврат будет не при каждом переключении задачи, но при недостатке памяти+отсуствии_защиты+1_п� �реключаемая_страница все равно придется делать копирование время от времени. другой вариант - более серьезные ограничения накладываемые на задачи (макс. объем нижней памяти)

[lvd]

само собой _ВСЮ_ память процесса никто копировать никуда не будет. но, согласно некоторым сообщениям в соседних ветках:
1. код процесса живет в странице -> переключаемся на новую
2. часть выделенной памяти живет в куче (ниже #c000) поэтому если новому процессу надо много памяти в куче, то надо спрятать RW блоки текущего процесса и вернуть/выделить блоки для нового.

само собой такой изврат будет не при каждом переключении задачи, но при недостатке памяти+отсуствии_защиты+1_п� �реключаемая_страница все равно придется делать копирование время от времени. другой вариант - более серьезные ограничения накладываемые на задачи (макс. объем нижней памяти)

Я вот думаю, будет ли оно в таком виде вообще юзабельным и даст ли какие преимущества в случае с тем же аль-асмом например? После предложений, что код в страницах, а данные будут лдириться время от времени, у меня закрадываются сильные сомнения... =)

[elf/2]

После предложений, что код в страницах, а данные будут лдириться время от времени, у меня закрадываются сильные сомнения... =)

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

зы: возможно я не до конца понял идеи GriV'а и Vitamin'а, но если что они меня поправят