Кафедра«Программное обеспечение ЭВМ и информационные технологии»
Курсовая работа
на Тему: «Реализациясистемы управления реального времени в ОС Windows»
Содержание
1. Введение
2. Конструкторская часть
2.1. Общие принципы
2.2. Програмное обеспечение
2.2.1. Драйвер режима ядра
2.2.2. Управляющее приложение
2.2.3. Приложение для создания нагрузки
2.2.4. Обратная связь
3. Технологическая часть
3.1. Выбор средства разработки
3.2. Организация задержек
3.3. Взаимодействие с драйвером
4. Исследовательская часть
4.1. Цели и задачи
4.2. Конфигурация тестового стенда
4.3. Работа на небольших частотах
4.4. Точность изменения задержек
4.5. Точность работы таймера
4.6. Увеличение частоты срабатывания
4.7. Работа параллельно с другими приложениями
4.7.1. Нагрузка на подсистему GDI
4.7.2. Работа со страничными отказами
5. Заключение
Приложение 1. Исходный код управляющего потока
Приложение 2.Исходный код рабочего потока
1.Введение
Внастоящее время компьютеры прочно вошли в нашу жизнь. Сложно найти такой аспектповседневной жизнедеятельности, в которой еще не используется современнаявычислительная техника. Не являются исключением и различныенаучно-исследовательские работы. Так, к нам в руки попало специальноеустройство, предназначенное для аналого-цифрового и цифро-аналогого преобразованиясигнала на аппаратном уровне. С устройством поставляется специальный драйвердля работы в операционной системе (далее ОС) Windows.
Послепервых же экспериментов с устройством выяснилось, что работа с ним возможнатолько на небольших частотах обрабатываемого сигнала. При увеличении частотынаблюдается искажение сигнала связанное с тем, что система не успеваетобрабатывать приходящие данные и выдавать данные в ответ. Этот результат можносчитать закономерным, учитывая что ОС Windowsвообще говоря не является операционной системой реального времени. Однако, самаоперационная система содержит в себе набор средств, которые предположительномогут позволить создать систему управления реального времени в ОС Windows.
2.Конструкторская часть
2.1 Общие принципы
Однимиз возможных способов решения поставленной задачи может быть использованиеспециальных потоков реального времени ОС Windows.Такие потоки имеют приоритеты от 16 до 31 и выполняются в режиме ядра. Крометого, важным отличием таких потоков от обычных является то, что они являютсяпотоками с добровольной передиспетчеризацией. Это означает, что если такойпоток получает процессор (как системный ресурс), то он будет занимать его дотех пор, пока сам добровольно не вернет его системе, т.е. не перейдет всостояние блокировки (например в ожидание на функции WaitForSingleObject).
Именноэтой особенность системных потоков реального времени мы и попробуемвоспользоваться при реализации системы управления реального времени в ОС Windows.
2.2 Программноеобеспечение
Дляпроведения исследований нам понадобится следующий набор программных средств: драйверрежима ядра, управляющее приложение, приложение для создания нагрузки, обратнаясвязь.
Каждыйиз этих пунктов подробнее рассматривается далее в этом разделе.
2.2.1 Драйвер режимаядра
Длясоздания системных потоков нам необходимо использовать драйвер, которым в нашемслучае является драйвер виртуального устройства. Связано это с тем, что в ходенаших исследований использование реального устройства было невозможно, крометого, в этом не было острой необходимости. Работу реального устройства мы будемэмулировать при помощи еще одного системного потока внутри нашего драйвера.
Итак,при начальной инициализации (в функции DriverEntry) драйверзапускает два системных потока. Первый из них (эмулирующий реальное устройство,управляющий поток, см. Приложение 1) исполняется с приоритетом 31 и ждет насистемном объекте «ожидающий таймер» (waitabletimer). Это позволяет потокупробуждаться через заранее определенные промежутки времени и будить второйпоток, имитируя тем самым приход некоторых данных от внешнего устройства.
Второйпоток (рабочий поток, см. Приложение 2) выполняется с настраиваемым приоритетом(от 16 до 30) и предназначен для обработки данных приходящих от внешнегоустройства. Для этого он ждет на событии до тех пор пока оно не будет взведеноуправляющим потоком. Затем поток выполняет некоторое число холостых циклов напроцессоре для имитации обработки данных. Количество таких циклов зависит оттого, какую длительность задержки мы хотим использовать.
2.2.2 Управляющееприложение
Припомощи специального приложения происходит управление работой драйвера. Внешнийвид этого приложения показан на рис. 2.1.
/>
Рис2.1. Внешний вид управляющего приложения.
Верхняякнопка позволяют установить драйвер. Следующие три поля ввода позволяют задатьсоответственно приоритет рабочего потока (от 2 до 30), частоту запросов отэмулируемого внешнего устройства (в герцах) и задержку (в 100-наносекундныхинтервалах), которая будет использована для имитации обработки полученных отустройства данных.
Нижняякнопка позволяет применить сделанные изменения.
2.2.3 Приложение длясоздания нагрузки
Посколькув реальных условиях параллельно с нашим драйвером будут выполняться и другиеприложения, важно учесть это в ходе нашей исследовательской работы. Для этихцелей было разработано специальное приложение, внешний вид которого показан нарис. 2.2.
/>
Рис2.2. Внешний вид приложения для создания нагрузки (фрагмент)
Перваяпара кнопок позволяет включать или выключать нагрузку на подсистемы GDI,вторая пара кнопок соответственно влияет на генерацию множественных страничныхотказов.
2.2.4 Обратная связь
Дляопределения текущего состояния драйвера необходимо поддерживать с ним обратнуюсвязь. Из всех возможных способов такой связи был выбран самый простой —посылка текстовых строк отладчику ядра функцией DbgPrint.Для чтения таких строк можно использовать специальные программные средства, внашем случае будет использовано приложение DebugView4.31 от Марка Руссиновича (MarkRussinovich), внешний вид которогопоказан на рис. 2.3.
/>
Рис2.3. Приложение DebugView
3.Технологическая часть
3.1 Выбор средстваразработки
Дляразработки драйверов наиболее широкое применение получили языки C/C++и Ассемблер. Для разработки настоящего драйвера был выбран язык C++,поскольку он сочетает в себе простоту разработки программ с возможностьюиспользования ассемблерных вставок для критических участков кода. Кроме того,заголовочные файлы для этого языка идут в стандартной поставке DDK.Для сборки конечного драйвера использовались компилятор и линковщик из DDK.
3.2 Организациязадержек
Дляимитации обработки данных, полученных от устройства необходимо создаватьзадержки. Для этого можно использовать вызов специальной функции ядра KeStallExecutionProcessor,однако в этом случае мы не можем контролировать что на самом деле произойдет спотоком и мы получим меньше информации о том сколько тактов центральногопроцессора было востребовано.
Крометого, при реальной работе вместо фиктивных задержек будут использованы реальныематематические вычисления на центральном процессоре. Наиболее удачной имитациейэтого на наш взгляд будет создание холостых циклов при помощи ассемблерныхвставок например такого вида:
movecx, count
label:xchg eax,eax
looplabel
Здесьпараметр countопределяет, сколько именно холостых циклов нужно выполнить, причем мы дажеможем приблизительно предположить, сколько тактов центрального процессора наэто уйдет.
Дляприблизительного пересчета числа холостых циклов во временные интервалы при начальнойинициализации драйвера выполняется порядка 108 холостых циклов свычислением времени которое было затрачено на эту операцию. Далее необходимоечисло холостых циклов для организации задержки рассчитывается по следующейформуле:
/>,
гдеcountи timeсоответственно количество холостых циклов и время на их выполнение приначальной инициализации драйвера, time— требуемая длина задержки.
3.3 Взаимодействие сдрайвером
Управлениепараметрами работы драйвером производится при помощи следующей структуры:
structControlStruct
{int Priority;
intFrequency;
intDelay;};
ПолеPriorityзадает текущий приоритет рабочего потока драйвера (приоритет управляющегопотока всегда 31). Поле Frequency задает частотуприхода данных от эмулируемого внешнего устройства. Поле Delayопределяет длительность задержек на обработку данных от устройства.
Передачаобновленной структуры из управляющего приложения в драйвер осуществляетсяследующим образом. Приложение открывает виртуальное устройство, ассоциированноес драйвером, а замет вызовом WriteFile передает вдрайвер нужные данные.
Драйверполучает данные в своей функции DispatchWrite и сохраняет их в глобальнойпеременной, внося необходимые изменения в свою работу.
4.Исследовательская часть
4.1 Цели и задачи
Длятого чтобы начать исследование, необходимо определиться, как будетиспользоваться полученное программное обеспечение в ходе его проведения, икаких результатов мы хотим добиться.
Припомощи управляющего потока мы будем имитировать работу реального устройства нанекоторой частоте. Начав с небольших частот мы попытаемся довести частоту до 1кГц и добиться устойчивой работы на ней.
Следуеттакже определиться с тем, что мы будем понимать под устойчивой работой.Поскольку речь идет о системе управление реального времени, то необходимо,чтобы к моменту прихода следующего запроса от устройства предыдущий был ужеполностью обработан. Если по приходу запроса мы обнаружим что предыдущий запросеще обрабатывается, мы будем считать что на данной частоте с данным временемзадержки на используемой системе реализация системы управления реальноговремени невозможна.
4.2 Конфигурациятестового стенда
Исследованияпроводились на компьютере со следующей конфигурацией: AMDDuron 1000 MHz,EPoX 8KHA+(VIA KT266A),384 MbDDR SDRAM.Файлы подкачки системы располагались на винчестерах SeagateBarracuda и WesternDigital со скоростью вращенияшпинделя 7200 об/мин, подключенными по интерфейсу IDE.
Операционнаясистема, установленная на тестовой машине, MicrosoftWindows XPPro SP2.Система недавно переустанавливалась, работает стабильно.
4.3Работа на небольших частотах
Начнемнаше исследование с запуска драйвера на небольших частотах, а именноограничимся частотой в 1 Гц и пронаблюдаем какие максимальные задержки мысможем выставить сохраним стабильную работу драйвера.
Дляпростоты пока будем предполагать что кроме нашего драйвера система больше незагружена никакими ресурсоемкими приложениями. То есть в диспетчере задач более95% процессорного времени приходится на псевдо-процесс Idle(«Бездействие системы»). Приоритет рабочего потока выставим в значение 16.
Частота1 Гц дает нам приход запросов от имитируемого устройства каждые 1000 мс.Изначально была выставлена задержка 100 мс. Это дает системе 900 мс на«накладные расходы», что позволило драйверу стабильно выполнить необходимыедействия. На прикладном уровне работа драйвера без привлечения специальныхсредств не ощущалась.
Затеммы стали увеличивать длительность задержки. Значение было доведено до 990 мс(что дает системе 10 мс на обработку «накладных расходов»). При такой задержкестабильная работа драйвера сохранилась, однако на прикладном уровне серьезноощущались «рывки» — система тратила 99% времени на обработку в драйвере.
Возможно,длительность задержки можно было еще увеличить, однако это было сделатьдовольно трудно, т.к. система плохо реагировала на действия пользователя. Призначении задержки 1000 мс, как и следовало ожидать, стабильность работыдрайвера нарушалась.
Ещенужно сказать о том, что если для частоты 1 Гц затраты на накладные расходысистемы длиной в 10 мс можно считать нормальными, то на более высоких частотах(выше 100 Гц) это будет недопустимо большой паузой.
4.4Точность изменения задержек
Далеепо ходу исследования нам будет необходимо увеличивать частоту запросов иуменьшать длительность задержек. Не лишним будет по логу работы драйвера убедится,что выбранный нами способ организации задержек работает корректно. На рис 4.1показан один из участков лога.
/>
Рис4.1. Точность измерения задержек
Началозадержки 990 мс — время 398.11619158, конец — 399.10677251. Расхождение срасчетным временем составило 0.00058093 с. Конечно, при уменьшении задержек ипри включении внешней нагрузки погрешность увеличится, однако такой результатвсе равно можно назвать достаточно хорошим.
4.5 Точность работытаймера
Вместовнешнего устройства мы использовали ожидающий таймер, поэтому интересно будетпроверить, насколько точно он позволит нам выдерживать необходимую частотусрабатывания. На рис. 4.5 представлены два момента срабатывания таймера длячастоты 1 Гц.
/>
Рис.4.5. Точность работы таймера
Каквидно, разница составила 0.000195 с, что тоже можно считать хорошимрезультатом.
Посмотримкакие задержки мы сможем использовать в случае более высоких частот (до 1 кГц)и что будет если запустить драйвер не на «холостых оборотах» системы, а с наличиемвнешней нагрузки.
4.6 Увеличение частотысрабатывания
Драйвербыл запущен для частоты 1 кГц. Увеличивая постепенно время задержки былополучении предельное значение около 200 мкс. Как видно, увеличение частоты в1000 раз привело к уменьшению длительности задержки более чем в 1000 раз. Впринципе даже такого интервала задержки могло бы хватить для реализации системыуправления реального времени, однако следует учесть еще один фактор. В реальнойсистеме помимо нашего драйвера выполняются еще и другие приложения, которыетоже требуют процессорного времени и других системных ресурсов. Проверим работудрайвера в присутствии таких приложений.
4.7 Работа параллельнос другими приложениями
Дляпроведения исследования этого рода было написано специальное приложение,которое может создавать нагрузку определенного рода.
4.7.1Нагрузка на подсистему GDI
Известно,что подсистема GDIWindows имеет свой системныйпоток с приоритетом реального времени. Можно ожидать, что при большомколичестве запросов к этой подсистеме может вызвать сбой в работе нашегодрайвера. Проверим это.
Драйвербыл запущен на частоте 1 кГц параллельно с приложением, выполняющим активноерисование средствами GDI.Стабильная работа драйвера сохранилась, однако графический вывод производился сзаметными «рывками».
4.7.2 Работа состраничными отказами
Серьезнойпроблемой могут стать страничные отказы, происходящие в системе. Запуск начастоте 1 кГц параллельно с приложением, генерирующем множественные страничныеотказы дал очень интересные результаты. Драйвер не смог выдержать временныезадержки в 200 мкс. Более того, даже более короткие задержки (до 25 мкс) недавали устойчивой работы драйвера.
/>
Рис4.6. Остановка при обнаружении сбоя
Ситуацияменяется к лучшему при увеличении приоритета потока драйвера. Можнопредположить, что обработка страничных отказов выполняется также при помощисистемного потока. Если мы устанавливаем свой приоритет выше его, тостабильность работы повышается. На приоритете 30 и частоте 1 кГц удалосьдобиться стабильной работы при страничных отказах с задержками до 100 мкс.
5.Заключение
Мыпронаблюдали работу драйвера, предназначенного для реализации системы реальноговремени, содержащего в себе системный поток, выполняющийся с приоритетомреального времени.
Послепроведения некоторого количества экспериментов были получены допустимые временазадержек для частоты 1 кГц в «холостом» режиме работы системы и в режимемножественных страничных отказов. Для тестовой системы в первом случае времясоставило 200 мкс, а во втором 100 мкс.
Теоретическийпредел для частоты 1 кГц очевидно 1000 мкс, т.е. для полезной обработки данныхвнешнего устройства могут быть использованы 10—20% процессорного времени.
Присоблюдении этих условий на операционной системе Windowsможет быть реализована система управления реального времени предложенного типа.
Приложение1
Исходный код управляющего потока
VOIDTimerThreadProc(PVOIDstartContext)
{TRACE("->TimerThreadProc, IRQL = %d",
KeGetCurrentIrql());
KeSetPriorityThread((PKTHREAD)pTimerThread,31);
KPRIORITYpriority =
KeQueryPriorityThread((PKTHREAD)pTimerThread);
TRACE(«TimerThreadPriority: %d»,priority);
SetTimer();
while(!bExitThread)
{KeWaitForSingleObject(&kTimer,
Executive,KernelMode,FALSE,0);
if(bExitThread) break;
LONGstate = KeReadStateEvent(&kEvent);
if(state == 0)
{TRACE(«TimerThreadProc:KeSetEvent»);
KeSetEvent(&kEvent,FALSE,FALSE);}
else
{TRACE("[!]Event already in signaled "
«state;aborted»);
bTimerWorks= false;
break;}}
KillTimer();
TRACE("
PsTerminateSystemThread(STATUS_SUCCESS);}
Приложение2
Исходныйкод рабочего потока
VOIDThreadProc(PVOIDstartContext)
{TRACE("->ThreadProc, IRQL = %d",KeGetCurrentIrql());
KeSetPriorityThread((PKTHREAD)pThread,curSett.Priority);
for(inti = 0;!bExitThread;i++)
{TRACE("*ThreadProc: loop %d, "
«priority%d»,i,
KeQueryPriorityThread((PKTHREAD)pThread));
KeWaitForSingleObject(&kEvent,Executive,KernelMode,
FALSE,0);
if(bExitThread) break;
//имитируемработу
TRACE(">>Start \«working\»");
DELAY(curSett.Delay);
TRACE(">>Stop \«working\»");
//сбрасываем событие чтобы снова начать его ждать
KeResetEvent(&kEvent);}
TRACE("
PsTerminateSystemThread(STATUS_SUCCESS);}