OSDev

Вмешиваясь в работу таймерного задания мы необосновано увеличиваем время отклика всей системы. Если этот вариант настолько-же прост, как популярен, то я зубная фея. Лично я сторонник таких механизмов, которые дают абстракцию, но не берут слихвой того, что можно на них с!экономить) Могу предложить пару альтернатив, но они зависят от того, жёсткого система времени или мягкого... "Какое, Фауст, ты предпочитаешь?"))

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

Вообще сейчас широко используется такой алгоритм обработки прерываний. Обработчик делится на 2 логические части. Первая часть делает короткие, но первоочередные обращения к устройству. Эта часть работает без квантования, до момента самостоятельного завершения. Затем управление передаётся второй логической части, которая выполняет дополнительную и более длительную работу с устройством, но в режиме разделения времени с прочими потоками.

Нечто похожее я встречал в ядре линукса (кажется от 2.4...). При компиляции есть возможность отказаться от прерываний по таймеру, и переключаться при любом другом аппаратном прерывании. Интересная тема. Таймерным заданием я называю "модуль", который занимается программированием системного таймера, так что мы говорим об одном (Это в Миниксе так...))
-Для софттайма напрашивается вариант предоставления потоку, занявшему разделяемый объект дополнительного кванта времени, причем сразу после того, как истёк первый квант. Т.е. время, которое поток проведёт в кр/секции должно быть невелико и предсказуемо. Этот вариан не подходит для потоков, разделяющих ввод-вывод, увеличивает время отклика и понижает предсказуемость систимы.
-Второй вариант сложнее: берём все ситуации разделенного доступа и делим их на два лагеря.
1. С непредсказуемым временем нахождени в КС.
В этот лагерь могут попасть операции по работе с устр. в/в и т.д. Для них применяем традиционные механизмы синхронизации (семафоры, мутексы, мониторы и т.д.).
2. С предсказуемым временем нахождени в КС.
Здесь можно выделить механизмы IPC. При обмене данными обеспечиваем атомарность не на уровне захвата мутекса, а на протяжении всей транзакции:)) Естественно, по скорости такие IPC должны быть сравнимы с операцией по захвату мутекса (или другой дряни) и выполнятся за несколько тактов процессора!
Второй способ лишён недостатков первого. Он повышает предсказуемость системы, а все внутрисистемные операции обмена данными укладываются в кванты времени самих процессов/потоков. Но здесь сложность заключается в разработке быстрых и надёжных IPC. Чем я и занимаюсь в данный момент)

Да-уж. Сравнение с линуксом, конечно, так себе, но муть наверно та ещё?!))) Не совсем понял про два логических уровня. Получается, что первый занимается активным опросом? Можно по-подробней... Или где найти такой метод можно почитать.

Детальной информацией не владею. Другими словами, речь идёт о двухэтапном взаимодействии с устройством. Логика работы как таковая не изменяется, просто одна большая процедура делится условно говоря на 2 небольших процедур. Исполняются они друг за другом, как если бы это была единая процедура, но исполняются разным темпом. Первая процедура исполняется в невытесняемом режиме, и может занимать например 1,5 кванта. Вторая процедура исполняется планировщиком в порядке общей очерёдности.

Данная архитектура драйвера позволяет использовать низкоскоростные IPC. Обычно в первой части драйвер читает данные в буфер памяти, а вторая часть отсылает данные через IPC в пользовательскую программу.

Всё, спасибо я понял. Кстати между нашими алгоритмами есть общий момент. Только в твоём случае атомарность доступа реализуется отменой квантования, а в моём пониженим время транзакции! Классный алгоритм! Спасибо) Мне кажется наши алгоритмы можно совместить:
-твой для ввода-вывода.
-а мой для айписи.
А я голову ломал)) Как тебе идея?

Конечно. Нет предела совершенству :)

Надо заметить, что слишком много чести драйверу иметь возможность выключать квантование, особенно, учитывая что это самый ненадёжный компонент системы. А как выключить квантование? -запретить прерывания? Тогда еще рискуем пропустить важноем аппаратное событие. Вот что предлагаю:
Если нам известно сколько максимум квантов потребуется на нахождение в критической секции (допустим 2 кванта), то:

*** Драйвер ***
Собрались в КС:
- Устанавливаем флаг в 1. (Мы в КС)
- Устанавливаем счётчик в 2. (Собираемся сидеть 2 кванта)
Выходим из КС:
- Обнуляем флаг.
- Обнуляем счётчик.

*** Обработчик таймерного прерывания ***
- Читаем флаг.
-Если 0, то передаём управление диспетчеру.
-Если 1, то читаем счётчик драйвера.
- Счётчик больше нуля, значит уменьшаем его (-1) и возвращаем управление драйверу.
- Счётчик 0 (позарились на третий такт) - выдаём сообщение об ошибке (драйвер повис) и блокируем драйвер до выяснения обстоятельств (или завершаем), устанавливаем флаг в 0 и передаём управление диспетчеру.

Изменил этот пост. - сделал поспешные выводы. Есть некоторые мысли по организации интересного способа раздельного доступа, но они требуют детальной теоретической "обработки". Потом буду тестить (наверно на миниксе). Если интересно, выложу способ и результаты. Еще раз спасибо за хорошую идею))

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