OSDev

Спасибо, хорошая статья!

TSS, как его не назови, (хоть сегмент состояния задачи, хоть область памяти для хранения контекста потока) не начнёт от этого меньше весить. Технически красиво, когда логика работы системы не нарушает логику работы программы. Потоки в вытесняющей ос не могут не знать о том, что система многозадачная, т.к. явно вызывают функции синхронизации.
{На базе вытесняющей системы (со всеми её достоинствами) можно в любой момент реализовать кооперативную систему в одном из потоков. Обратная ситуация - невозможна или нецелесообразна.} <- главный аргумент.

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

Прошу не путать виртуализацию и многозадачность. Но даже если запустить Дос в отдельном потоке, а не виртуальном окне, то станет вопрос: а смысл? - всё равно он не сможет общаться с остальными потоками, т.к. придётся явно вызывать механизмы ядра, и придётся считаться с остальными потоками: в этот порт не лезь, в эту память не пиши, прерывания не запрещай... Т.е. ему ПРИДЁТСЯ знать о системе.

Лично для меня кудааа сложнее представление в виде БД:) Не шарю я в них.. А файловая система - это условно. "Древовидная структура" или "Снежинка" куда ближе подходит.

Потоки - да , а программы - приложения могут с помощью "обёрток" системы. Есть какие-то старые оси существующие в вариантах одно и много-задачности. Советские вроде. Приложения работают.

Значит виртуализация... или режим бога;)

О, тролл-вечеринка все еще в разгаре! )))

В кооперативке тоже нужно где-то сохранять контексты потоков.

Когда всем задачам процессорного времени поровну, это не красиво, а убого. Если пользовательский поток начнет конкурировать с ядерным потоком, в котором к примеру выполняется доводчик прерывания (вторичный обработчик прерывания/отложенный обработчик прерывания/вторая половинка), то из этого ничего хорошего не получится. Связи между отсутствием TSS и равномерным распределением времени между потоками вообще не увидел.

Некоторые синхронизирующие вызовы не относятся к взаимодействию с другими процессами/потоками в явном виде, к примеру тот же waitevent (у меня это чисто консольный механизм, поэтому даже в setevent/resetevent нет указания на получателя в явном виде). Поэтому я бы сказал, что некоторые программы могут и не знать, что они выполняются в многозадачной системе.

Ошибочно считать, что в кооперативке нет сохранения контекста. Может быть, не требуется сохранения четырёх регистров - EAX, EBX, EDX, ECX, ESI, EDI (хотя я бы во избежание глюков сохранял бы и их), но контекст всё же гораздо больше этого набора регистров (не только регистры описывают состояние задачи) и всё остальное должно сохраняться при переключении задачи.


При управлении звездолётом простая оптимизация даст на порядок больший эффект, чем отказ от сохранения 6 регистров :)

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.
<<< OS Boot Tools. >>>

Удивительное явление!

Да нету в кооперативке такого понятия как контекст. Нету, и всё. Всё - один поток кода. Регистры в перименных сохраняются. Тупо в перименных. Этим компилятор занимается, не разработчик ядра ос. Обычное выражение на паскале: А:=А+1 выглядит как: мув ах, а адд ах, 1 мув а, ах <- ключевой момент. Да и в любой момент "критичные потоки ядра" можно реализовать с вытеснением. А вы знаете что такое "Алгоритм Банкиров"? Это когда нужно просчитать все потенциальные взаимные блокировки в многопоточной вытесняющей системе. С матрицами здесь все "на ура"?