OSDev

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

логика "само"организации потоков.Также серв. способны исполняться в конт. клиентов.Пиши в асю,блин

Мне пришла идея про упорядочение потоков.
1. Короткое задание должно выполняться с большим приоритетом, чем конкурирующее длинное. Это связано с тем, что пользователь интуитивно ожидает быстрого выполнения короткого задания, а большое задание морально готов ждать дольше.
2. Когда потоки активно используют общий ресурс типа диска, эффективность работы которого максимальна при упорядоченном чтении, а при фрагментарном и хаотичном чтении эффективность снижается, то планировщик должен увеличить длительность квантов, тем самым уменьшая дробление вычислений. Драйвера дисковых накопителей обычно решают эту проблему путём упреждающего чтения (оптимистично полагая, что прочитанные заранее данные будут вскоре востребованы), но он не совсем оптимален.

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

Насчёт 2 -- сами запросы осью должны переупорядочиваться. Например, сначала запросы исполняются в порядке возрастания номеров блоков, потом -- в порядке уменьшения, т.е. головки ползают вдоль диска в одном направлении до конца, а потом обратно. Ну и т.д. Тут есть кой-какие варианты, но смысл один и тот же по-любому: переупорядочивать запросы.

Я пожалуй не против классификации.
Да, я теперь понял как нужно. Только предусмотреть ограничитель, связанный с длительным чтением большого файла (как воспроизведение фильма), иначе другие потоки будут в длительном простое.

После долгого оффлайна решил зайти на форум, посмотреть что новенького. Приятно удивился количеству просмотров своего старого топика:) Мельком пробежав по постам более, чем годовалой давности решил признать победу в споре за SII. - мне так и не удалось представить эффективный механизм избежания вредных дэд- и лайфлоков, достаточно универсальный и прозрачный для прикладного программиста.
А идея SII, действительно, оказалась универсальной: "...грамотно реализованный поток!".
Могу представить такой грамотный поток (без привязки к обсуждаемой теме), реализованный в виде протопотока или сопрограммы. Они обладают всеми достоинствами и недостатками кооперативного подхода:
Плюсы:
- Нет необходимости в примитивах синхронизации.
- Быстрое переключение контекста и скромный расход памяти на его хранение.
- Высокая скорость и простота обмена данными.*
- Поддержка на уровне языка или расширений.*
Минусы:
- Невытесняемость.
- Отсутствие адресной защиты.*
- Сложность разбиения программы на потоки.*
- Невозможность динамической дозагрузки и выгрузки.*
Звёздочкой я пометил моменты, присущие всему потоковому стилю программирования, а не только кооперативным его реализациям. Узким местом становится невытесняемость, которая и должна определить приемлемость применения протопотоков или сопрограмм.

Практически всем "моим" идеям по полвека. Как ни странно, но с конца 1960-начала 1970-х никаких существенных подвижек в осестроении нет, имеются лишь всякие внешние улучшения.

Тем не менее, считаю уместным в разделе теоретических вопросов обсуждать именно теоретические вопросы. Без привязки к конкретной архитектуре и языковой реализации. Ведь в информатике достаточно гибких абстракций и формализмов, позволяющих рассматривать теоретические вопросы осестроения в рамках простой логической модели.
Как мне кажется, многим участникам форума как раз не хватает понимания многих таких теоретических моментов, и многие здесь считают, что операционная система начинается с загрузчика или графического пользовательского интерфейса, упуская главное. То, чему "полвека"..

Кстати, вопрос к старожилам форума: кто и как использует программную многозадачность в своих осях? Если никто и никак, то каковы перспективы использования, области применения и способы реализации?
Лично у меня следующие варианты...
Способ представления:
- Объектная "языковая" модель.
- Автоматная модель.
- Модель акторов. (Много вопросов)
Выход из "зависаний":
- По таймауту.
Адресная защита и динамическая загрузка в "исполняемую среду":
- Больше вопросов, чем ответов.
Обработка асинхронных событий, критичных к времени реакции в "первичных" обработчиках.
??Область применения: от модулей ядра до пользовательских приложений.

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