22 - hal (Ответы на экзаменационные билеты), страница 4

На этом рисунке показан также динамический приоритет потока, нижней границей которого является базовый приоритет потока, а верхняя зависит от вида работ, исполняемых потоком. Например, если поток обрабатывает пользовательский ввод, то ядро NT поднимает его динамический приоритет; если же он выполняет вычисления, то ядро постепенно снижает его приоритет до базового. Снижая приоритет одного процесса и поднимая приоритет другого, подсистемы могут управлять относительной приоритетностью потоков внутри процесса. Базовый приоритет процесса определяет, сколь сильно могут различаться приоритеты потоков процесса и как они соотносятся с приоритетами потоков других процессов.

Как и приоритеты, другие атрибуты объекта-потока предназначены для того, чтобы предоставить ОС (и в частности, подсистемам среды) возможность управления созданным ею потоком. Например, контекст потока содержит все, что нужно ОС для возобновления исполнения прерванного потока: а именно, содержимое регистров процессора и стеков пользователя и ядра. Приостановив поток, изменив его контекст и запустив поток снова, подсистема среды может изменить его поведение или начать его выполнение с адреса, отличного от точки останова. (Этот способ могут также использовать отладчики пользовательского режима для управления выполнением потоков.)

Рис. 3-8. Соотношение приоритетов².

Hа рисунке показаны только потоки переменного приоритета, которые выполняются на уровне приоритета от 0 до 15. Потоки реального времени исполняются на уровнях приоритета от 16 до 31.

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

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

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

1. "Жесткие" и "мягкие" системы реального времени

Система реального времени (СРВ) - это аппаратно-программный комплекс, который должен своевременно и предсказуемо реагировать на поступающие извне раздражители. Основное требование к системе реального времени - своевременность обработки событий. Реакция на событие должна уложиться в пределы заранее определенного лимита времени, а превышение этого лимита или опоздание считается программным сбоем.

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

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

Итак, разница между жесткой и мягкой системами зависит от предъявляемых к ним требований. Система называется жесткой, если "система не должна опаздывать никогда", и мягкой, если "система не должна опаздывать, как правило".

Не следует путать операционную систему реального времени (ОС РВ) с системой реального времени. Первая ОС используется для создания системы реального времени. ОС РВ должна быть предсказуемой - это не значит, что она должна быть быстрой, это означает, что при построении СРВ можно добиться того, чтобы максимальное время, затрачиваемое на определенную работу, укладывалось в заранее установленный лимит, сравнимый с требованиями приложения. Windows 3.11, например, даже на сколь угодно быстром процессоре бесполезна для построения систем реального времени, поскольку любое приложение может захватить управление и заблокировать все остальное.

1. Удовлетворяет ли Windows NT требованиям, предъявляемым к операционным системам реального времени?

   1. Поддержка многопоточности

Очевидно, что NT - мультипотоковая ОС с абсолютным приоритетом, она позволяет вытеснение и тем самым удовлетворяет требованию 1.

В СРВ работы имеют различные приоритеты. Более критичные по времени получают более высокий приоритет. Другие же, например, отображение состояния системы, регистрация событий в файл или конфигурирование системы имеют более низкий приоритет. Чтобы учитывать эти различия, ОС должна уметь приписывать различные приоритеты этим работам.

В Windows NT понятие приоритета весьма сложное:

Имеется два класса приоритетов для процессов - класс реального времени и динамический класс. Процессы класса реального времени имеют фиксированный приоритетный уровень, который может быть изменен только в приложении, тогда как приоритеты процессов динамического класса меняются планировщиком в зависимости от типа работы, выполняемой процессом (интерактивный или не интерактивный). Только первый класс предсказуем и потому может быть использован в СРВ. Следует отметить, что для не требующей выполнения в реальном времени заявки в СРВ можно использовать второй класс, поскольку он не разделяет ресурсов с процессами класса реального времени.

Процесс имеет базовый приоритетный уровень, который может быть изменен только самим приложением.

Приоритет потока в процессе лежит в диапазоне +-2 к уровню базового приоритета и еще может принимать два граничных значения приоритета класса. Например, нити процесса с базовым уровнем приоритета 24 (класс реального времени) могут иметь приоритеты от 22 до 26, а также 16 и 31.

1. Приоритет потоков

Итак, поскольку есть понятие приоритета потока, требование 2 формально выполнено. Однако, имеется одна проблема: приоритетных уровней мало. Большинство современных ОСРВ допускают по крайней мере 256 приоритетов. Почему это проблема? Ответ очевиден: чем больше приоритетов - тем более предсказуема система. Лучший способ при проектировании системы - приписать отдельный приоритет каждому потоку. Процессу в Windows NT предоставляется только 5 (7 с учетом граничных) приоритетных уровней для потоков. Поэтому многим из них придется делить один и тот же уровень. Предсказуемость будет весьма невысокой, если нужно будет обрабатывать более одного или двух критических событий. Можно возразить, что это могут делать разные процессы. Но и тогда общее число приоритетов - лишь 16. Кроме того, время переключения контекста между потоками из разных процессов много больше, чем между потоками одного процесса, ибо они функционируют в разных адресных пространствах (общее пространство памяти - атрибут контекста). Таким образом, Windows NT дает не лучшее решение.

1. Инверсия приоритетов

Как говорилось выше, инверсия приоритетов является классической проблемой для СРВ. Поэтому в ОСРВ синхронизирующие систему механизмы: совместное блокирование (mutex), семафоры, критические участки кода (critical sections) должны учитывать наследование приоритета. В Windows NT это НЕ РЕАЛИЗОВАНО, поэтому требование 4 не выполнено. Другая проблема, связанная с инверсией приоритетов в Windows NT, обусловлена особенностями реализации некоторых системных вызовов, относящихся к GUI. Они обрабатываются синхронно (вызвавшая нить приостанавливается до завершения системного вызова) процессом, не принадлежащим классу процессов реального времени. Значит поток более низкого приоритета из класса реального времени может задержать выполнение более приоритетного потока.

Как мы установили, относительно небольшое число приоритетов, приводящее к проблеме инверсии приоритетов, делает Windows NT пригодной разве лишь для простых СРВ (с небольшим числом типов событий).

1. Характеристики Win32 API

Зачем нужна Windows NT? Как упоминалось выше, было бы желательно иметь одну и ту же ОС на всех уровнях индустриальной иерархии компании. Другой интересный кандидат на эту роль - богатая возможностями и мощная система Win32 API. Здесь имеется множество хороших платформ для разработки, компиляторов, причем существует масса специалистов, которым она хорошо знакома. Возможности ее многочисленны. Здесь есть все для создания многопотковых приложений. Осталось выяснить можно ли создавать в Win32 API приложения реального времени.

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

Для измерений мы провели несколько простых тестов. Мы создали процесс, принадлежащий классу реального времени, который имел поток, выполняющий синхронизирующие системные вызовы. Мы использовали системный вызов QuerryPerformanceCounter до и после каждого синхронизирующего вызова для измерения времени его выполнения. В конце мы сохранили все результаты на диске для обработки в Excel.

Мы убедились, что в течение теста не было своппинга и никакой ресурс не был заперт. Мы также измерили задержку, обусловленную измерениями, и вычли ее из результата. Тесты были выполнены на Pentium 100 с 24MB RAM.

Например, для системного вызова типа "совместная блокировка" мы получили среднее время выполнения 35 мксек. При этом максимальное время (однажды) достигло 670 мксек.

Почему? Эти задержки были следствием прерываний либо от диска либо от сети (тестируемая машина была подсоединена к сети), так как иных видов деятельности не было. Мы воспроизводили ситуацию много раз, искусственно загружая машину передачами на диск и в сеть. В итоге удалось получить времена задержки системных вызовов до нескольких миллисекунд!!!

Как уже говорилось Win32 API очень мощная система, но, нужно заметить, она не предназначена для работы в реальном времени. Например, очередь запросов совместной блокировки организована по правилу FIFO, а не по приоритетам. Это существенный недостаток с точки зрения предсказуемости. Следует соблюдать осторожность и в отношении того, какие системные вызовы лучше использовать. Например, для синхронизации потоков внутри одного процесса механизм критических участков кода более предпочтителен по сравнению с другими (вызов этого типа выполняется за несколько микросекунд, а не 35 мксек как совместная блокировка). Этот вызов предназначен для использования именно в данной ситуации. Эта быстрота не удивительна, поскольку переключение контекста нитей внутри процесса намного проще, чем между процессами.

Последнее замечание относительно Win32 API: при использовании системных вызовов API следует иметь в виду, что некоторые из них выполняются процессами более низкого приоритета (из динамического класса) и являются синхронными. То есть, вызывающая нить будет ждать завершения вызова. Это ведет к инверсии приоритетов.

После описанных тестов мы пришли к заключению, что несмотря на мощный API, основное ядро и администратор ввода/вывода не приспособлены для обработки событий прикладного уровня в режиме реального времени!

Ниже мы обсудим, можно ли решить эту проблему на уровне драйверов.

1. Управление прерываниями

СРВ взаимодействует с внешним миром через аппаратуру компьютера. Внешние события, поступающие в систему в виде прерываний, обрабатываются драйверами устройств.

Рис. 4 в документации DDK показывает, как Windows NT взаимодействует с аппаратурой. Доступ к аппаратуре возможен только через драйвер устройств ядра. Это логично в такой ОС, ибо процессы функционируют в различных адресных пространствах и не имеют прямого доступа к устройствам. Так как большинство приложений реального времени имеет дело со специфическими внешними событиями, разработчикам приходится писать драйверы устройств ядра, чтобы обеспечить доступ к аппаратным средствам. Посмотрим как устроен драйвер устройства.

Драйвер устройства отвечает за обработку прерывания, генерируемого устройством, которым он управляет. Чтобы повысить ответственность ОС за обработку был разработан оригинальный механизм. Прерывания обрабатываются в два этапа. Во-первых прерывание очень быстро обрабатывается ISR. После этого работа завершается выполнением процедуры DPC (Deffered Procedure Call). Это порождает следующую последовательность событий:

Происходит прерывание.

Процессор сохраняет PC, SP и вызывает диспетчер.

ОС сохраняет контекст и вызывает ISR.

Драйвер устройства выполняет в кратчайшее время наиболее критическую часть ISR (чтение/запись запросов от устройства).

Драйвер устройства вызывает функцию DPC (на самом деле это очередь, обрабатываемая администратором ввода-вывода).

Драйвер устройства выходит из ISR.

ОС восстанавливает контекст.

Процессор восстанавливает PC и SP.

Исполнение приостановленного вызова DPC происходит на приоритетном уровне DISPATCH\_LEVEL. Это уровень программного прерывания.

После выполнения всех висящих DPC ОС перепланирует приложения пользователя.

Как мы видим, обработка прерываний в Windows NT достаточно сложна. При этом ISR должна работать как можно быстрее. Поэтому большинство драйверов выполняют большую часть работы в DPC (который может прерываться только ISR), замедляя работу других DPC, так как все они обрабатываются на одном приоритетном уровне.

Документация на драйверы устройств Windows NT говорит, что "ISR может прерываться ISR более высокого приоритетного уровня и теми DPC, которые имеют более высокий приоритет, чем пользовательские и системный поток". Но так как все DPC имеют один и тот же приоритетный уровень и так как при проектировании драйвера устройства следует делать ISR как можно короче, перенося большую часть работы в DPC, при выполнении вашему DPC придется ждать пока не будут завершены все остальные DPC. Поэтому ваше приложение будет зависеть от драйверов устройств, обслуживающих другие приложения.

Устроено ли это по разному в разных ОСРВ? Естественно, это так. Разработчик ОСРВ вначале должен выяснить на каком приоритете работают другие драйверы устройств. Обычно имеется некоторая свободная память сверх занимаемой стандартными драйверами. Вся критическая работа выполняется в ISR, и у разработчика остается возможность сконфигурировать драйвер в зависимости от временных ограничений приложения. В Windows NT ISR очень быстрая, поэтому прерывания не блокируются надолго, однако ISR делает очень мало работы. Большая часть работы перекладывается на DPC. Поэтому, если вы используете плохо написанный драйвер, вы в конце концов нарушите временные ограничения по крайним срокам, если конечно вы не последуете стратегии Microsoft и не станете выполнять всю работу в ISR (но тогда зачем вообще нужна ОС?).