Курсовая работа ( по дисциплине “Организация ЭВМ и вычислительных систем”) «Операционные системы реального времени»




Скачать 111.44 Kb.
НазваниеКурсовая работа ( по дисциплине “Организация ЭВМ и вычислительных систем”) «Операционные системы реального времени»
Дата публикации17.03.2013
Размер111.44 Kb.
ТипКурсовая
odtdocs.ru > География > Курсовая


Министерство образования российской федерации

Московский государственный институт электроники и математики

(технический институт)
Кафедра ИКТ


КУРСОВАЯ РАБОТА

( по дисциплине “Организация ЭВМ и вычислительных систем”)
«Операционные системы реального времени»

Выполнила: студентка группы С-35

Ухина О.В.
Проверил: Мартиросян С.Т.
Москва

2009

Оглавление

Введение 3

Поставленные задачи 4

Архитектура ОСРВ и требования к ней 4

Практическая часть 8

Установка QNX 8

Тест на инверсию приоритетов 8

Особенности написания прикладных программ под QNX 12

Заключение 12


Введение


Что такое операционная система реального времени (ОСРВ)? Это ОС, в которой важно не только успешное выполнение программы, но и время, за которое она выполнилась. Главный параметр — время. Отсюда ОС делятся на системы общего назначения и ОС реального времени. Основная задача ОС общего назначения — эффективное распределение ресурсов ЭВМ (таких как процессорное время, оперативная память и т.п.) между несколькими одновременно выполняющимися программами. Такие ОС поставляются с богатым набором прикладных программ (приложений) и имеют развитый графический интерфейс, позволяющий пользователям работать с приложениями, не задумываясь над внутренними механизмами ОС. А ОС реального времени разрабатываются в расчете на наличие внешних источников данных. Основная задача ОСРВ — своевременно обработать запрос, все аспекты функционирования ЭВМ отходят на второй план. Поэтому ОСРВ поставляются в комплекте с разнообразными средствами разработки приложений. Другими словами, покупателями ОСРВ являются не конечный пользователи, а разработчикам, например, специализированных устройств и управляющих систем промышленного назначения, встраиваемого оборудования и систем реального времени, которых ждет нелегкий труд при разработке программ и на которых лежит огромная ответственность. Так же ими могут интересоваться студенты, изучающие компьютерные специальности, преподаватели, практикующие программисты: как рабочий стенд для разработки UNIX совместимых приложений, которые затем могут переноситься в другие ОС. О трудностях и особенностях написании кода пойдет речь далее в работе.

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

Вообще, система реального времени включает в себя:

  1. Прикладное программное обеспечение;

  2. Операционную систему реального времени;

  3. Аппаратное обеспечение.

Чем отличаются ОС жесткого и мягкого времени? ОС жесткого времени гарантирует выполнение каких-либо действий за определённый интервал времени. А ОС мягкого реального времени, как правило, успевает выполнить заданные действия за заданное время, т. е. ОС мягкого реального времени выполняет задачу с каким-то значением вероятности. ОС жесткого реального времени не допускаю задержки реакции системы, так как это влечет за собой серьезные последствия. Соответственно важна безупречная работа и самой ОС, помимо выполнения ею программ.

^ Современные ОСРВ

В данной работе будет рассматриваться ОС QNX (установка, работа и разработка прикладных программ в ней). Это одна из самых популярных ОСРВ, помимо VxWorks и Windows CE.

POSIX-совместимость

POSIX-совместимость — большое преимущество QNX.

QNX Neitrino поддерживает:

  • Простоту переноса и функциональную совместимость приложений между системами, поддерживающими стандарт POSIX, включая Linux и Unix - в большинстве случаев перенос сводится к перекомпиляции и компоновке с библиотеками QNX Neutrino.

  • Чистоту реализации стека протоколов IP, который получает гибкость прикладной среды открытого стандарта POSIX, снижая риск нарушения авторских прав.

  • Знакомую среду разработки, позволяющую программистам с опытом работы в UNIX или Linux освоиться в QNX Neutrino практически мгновенно.
^

Поставленные задачи


  • Исследовать архитектуру и особенности ОСРВ, так как из нее вытекают некоторые проблемы работы системы, например, инверсия приоритетов.

  • Выяснить, почему возникают трудности при написании программ: написание драйверов и программирование для GUI, программирование в сетях(написание кода в PhAB - Photon Application Builder, Photon QNX, примеры на С/С++)
^

Архитектура ОСРВ и требования к ней


ОСРВ бывают нескольких типов архитектур:

  1. Монолитная ОС — ОС представляет собой набор модулей, взаимодействующих между собой, которые предоставляют входные интерфейсы для обращений к аппаратуре. Из-за сложного взаимодействия модулей возникает непредсказуемое поведение ОС.

  2. Уровневая ОС, например MS-DOS. Прикладные программы в них могут напрямую обращаться к аппаратуре, а не только посредством ядра и резидентных сервисов. Преимущества — быстрый доступ прикладных приложений к аппаратуре, наибольшая предсказуемость по сравнению с монолитными ОС. Недостаток — отсутствие многозадачности. Проблема обработки обработки асинхронных событий сводилась к их буферизации, а затем последовательному опросу и обработке. Но соблюдение критических сроков обслуживания обеспечивалось высоким быстродействием комплекса по сравнению со скоростью протекания внешних процессов.

  3. Одна из наиболее эффективных архитектур для построения СРВ является клиент-сервер архитектура. В такой архитектуре выносятся сервисы ОС на уровень пользователя в виде серверов, микроядро является диспетчером сообщений между пользовательскими программами и серверами — системными сервисами. Такая архитектура дает много преимуществ: повышается надежность ОС, так как каждый сервис является самостоятельным приложением, которое легко отладить и отследить ошибки; система лучше масштабируема, так как можно отключать ненужные сервисы, и это не повлияет на ее работоспособность; повышается отказоустойчивость, так каждый модуль может быть перезагружен без перезагрузки системы. QNX имеет клиент-серверную архитектуру.

Функциональные требования к ОСРВ

^ Основным требованием к ОС является реализация в ней многозадачности. Такие требования предъявляются и к системам общего назначения, но для ОСРВ предъявляется ряд дополнительных требований, которые определяются обязательным свойством ОСРВ — предсказуемостью.

Многозадачность подразумевает параллельное выполнение нескольких действий. На практике реализация многозадачности упирается в совместное использование ресурсов вычислительной системы.

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

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

Приоритет потока — целочисленное значение, на основании которого ОС принимает решение, когда предоставить потоку время процессора. Количество приоритетов определяется ОС. В QNX их 64, а в VxWorks — 256.

Состояния потока




Методы диспетчеризации потоков

  • FIFO ( First In First Out) — Первый Вошел — Первый вышел. Сначала выполняется задача, которая первой вошла в очередь. Она выполняется пока не будет выполнена, либо пока не будет заблокирована в ожидании ресурса или какого-то события. После этого управления передается другой задаче в очереди. Такой механизм применяется, если у задач одинаковый приоритет.

  • ^ Карусельная многозадачность (round robin). В этом методе диспетчеризации задается константа — квант времени (time slice). Выполнение потока завершается либо при окончании его выполнения, либо при блокировании его в ожидании ресурса, либо при окончании кванта времени. После этого управление передается следующему потоку в очереди. По окончании выполнения последнего потока управление передается первому потоку, находящемуся в состоянии готовности. Т.е. Выполнение каждого потока разбито на последовательность временных циклов. Этот метод присущ для потоков с разным приоритетом.

Как происходит передача управления между потоками с разными приоритетами?

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

  2. Решение этой проблемы — адаптивная многозадачность. Метод заключается в том, что приоритет потока, не выполняющийся в какой-то период времени, повышается на единицу. Восстановление исходного приоритета происходит после выполнения потока в течении одного кванта времени при блокировании потока. И тем самым при карусельной многозадачности, очередь более приоритетных потоков не может полностью заблокировать выполнение очереди менее приоритетных потоков.

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

На практике методы комбинируют. И важно, чтобы все потоки укладывались в критическое время обслуживания, тогда система называется диспетчируемой.

В 1970 году Лиу и Лейленд предложили математический аппарат «Частотно монотонный анализ» для проверки систем на то, является ли она диспетчируемой, аппарат был принят в качестве стандарта такими организациями как USA Mitre, NASA, Boeing и др.

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

^ Механизмы синхронизации

Потокам так же необходимо разделять ресурсы, например переменные в памяти. Для защиты от искажения, вызванного одновременным редактированием одних и тех же данных разными потоками, используются переменные, которые называются объектами синхронизации. Это мютексы, семафоры, события. В задачах реального времени к этим объектам предъявляется специфические требования, так как на них возможны задержки выполнения потоков, поскольку их назначение — блокирование доступа к некоторому разделяемому ресурсу. Проблема, возникающая при блокировании ресурса, - инверсия приоритетов. Это когда поток высокоприоритетный и низкоприоритетный разделяют общий ресурс, и есть еще один поток, имеющий средний приоритет среди них. Когда высокоприоритетный поток в состоянии готовности, а поток с низким приоритетом активен, и он заблокировал ресурс, то поток с более высоким приоритетом вытеснит с более низким, а ресурс останется заблокирован. И когда высокоприритетному потоку понадобится ресурс, то он сам перейдет в заблокированное состояние. Если в состоянии готовности находится только низкоприоритетный поток, то ничего страшного не произойдет, низкоприориттеный поток освободит заблокированный ресурс и будет вытеснен потоком с более высоким приоритетом. А если в момент блокирования потока с высоким приоритетом в состоянии готовности находится поток со средним приоритетом, то активным станет он, а с низким приоритетом опять будет вытеснен. И получит он управления после выполнения потока со средним приоритетом. И критическое время обслуживания потока с высоким приоритетом будет пропущено. Если это поток жесткого реального времени, то это недопустимо. Защита от нее заключается в наследовании приоритетов . Суть его в наследование низкоприоритетным потоком, захватившим ресурс, приоритета от высокоприоритетного потока, которому ресурс нужен. Есть еще один метод — Протокол Предельного Приоритета. Он заключается в добавлении к стандартным свойствам объектов синхронизации параметра, определяемого максимальным приоритетом потока, которые к объекту обращается. Если параметр установлен, то приоритет потока, который обращается к данном объекту синхронизации, будет увеличен до указанного уровня, и не сможет быть вытеснен никаким потоком, который сможет нуждаться в заблокированном ресурсе. После разблокирования ресурса, приоритет потока понижается до начального уровня, и так получается что-то вроде наследования приоритетов.
^

Практическая часть

Установка QNX


Тут красивые скриншотики, показывающие как я старалась, и возникшие проблемы.

Тест на инверсию приоритетов


Код программы, написанном на С/С++:

#include #include #include #include #include #include
#include const int THRNUM = 3, NCKL = 10, LINOUT = 5, BUFLEN = THRNUM * NCKL + 1; inline void workfun( int n ) { for( long i = 0; i < n; i++ ) double f = sqrt( 1. + sqrt( (double) rand() ) ); }; char buf[ BUFLEN ]; volatile unsigned ind = 0, nfin = 0; long nrep = 1000; bool bmutex = false, bsemaphore = false; static pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER; static sem_t semaphore, semfinal; void *thrfunc( void *p ) { int t = (int)p; if( t != 1 ) { if( bmutex ) pthread_mutex_lock( &mutex ); if( bsemaphore ) sem_wait( &semaphore ); }; struct timespec tv; tv.tv_sec = 0; tv.tv_nsec =(long)( 1e+6 ); sem_trywait( &semfinal ); nanosleep( &tv, &tv ); for( int i = 0; i < NCKL; i++ ) { buf[ ind++ ] = t + '0'; workfun( nrep ); }; if( t != 1 ) { if( bmutex ) pthread_mutex_unlock( &mutex ); if( bsemaphore ) sem_post( &semaphore ); }; if( ++nfin == THRNUM ) sem_post( &semfinal ); }; int main( int argc, char *argv[] ) { cout << "inverse test, QNX API, vers.1.05L" << endl; int c = 0; while( ( c = getopt( argc, argv, "hmst:" ) ) != -1 ) switch( c ) { case 'h': cout << "\t" << argv[ 0 ] << " [ h | { m | s } | t = value ]" << endl; exit( EXIT_SUCCESS ); case 'm': bmutex = true; break; case 's': bsemaphore = true; break; case 't': nrep = 1; for( int i = 0; i < atoi( optarg ); i++ ) nrep *= 10; break; default: exit( EXIT_FAILURE ); }; sem_init( &semaphore, 0, 1 ); cout << "repeating number = " << nrep; // << ", debug level = " << ndebug; if( bmutex ) cout << ", lock on mutex"; if( bsemaphore ) cout << ", lock on semaphore"; cout << endl; struct sched_param param; int polisy; pthread_getschedparam( pthread_self(), &polisy, ¶m ); pthread_attr_t attr; for( int i = 0; i < THRNUM; i++ ) { pthread_attr_init( &attr ); pthread_attr_setdetachstate( &attr, PTHREAD_CREATE_DETACHED ); pthread_attr_setinheritsched( &attr, PTHREAD_EXPLICIT_SCHED ); pthread_attr_setschedpolicy( &attr, SCHED_RR ); attr.param.sched_priority = param.sched_priority + i + 1; pthread_create( NULL, &attr, &thrfunc, (void*)i ); }; sem_init( &semfinal, 0, 0 ); sem_wait( &semfinal ); buf[ ind ] = '\0'; cout << buf << endl; exit( EXIT_SUCCESS ); };

Скомпилируем и запустим его на QNX. Вот вывод программы:

repeating number = 100000, debug level = 1

2[13:13] 2[13:13] 2[13:13] 2[13:13] 2[13:13]

2[13:13] 2[13:13] 2[13:13] 2[13:13] 2[13:13]

1[12:12] 1[12:12] 1[12:12] 1[12:12] 1[12:12]

1[12:12] 1[12:12] 1[12:12] 1[12:12] 1[12:12]

0[11:11] 0[11:11] 0[11:11] 0[11:11] 0[11:11]

0[11:11] 0[11:11] 0[11:11] 0[11:11] 0[11:11]

repeating number = 100000, debug level = 1, lock on mutex

0[11:13] 0[11:13] 0[11:13] 0[11:13] 0[11:13]

0[11:13] 0[11:13] 0[11:13] 0[11:13] 0[11:13]

1[12:12] 2[13:13] 2[13:13] 2[13:13] 2[13:13]

2[13:13] 2[13:13] 2[13:13] 2[13:13] 2[13:13]

2[13:13] 1[12:12] 1[12:12] 1[12:12] 1[12:12]

1[12:12] 1[12:12] 1[12:12] 1[12:12] 1[12:12]

repeating number = 100000, debug level = 1, lock on semaphore

1[12:12] 1[12:12] 1[12:12] 1[12:12] 1[12:12]

1[12:12] 1[12:12] 1[12:12] 1[12:12] 1[12:12]

0[11:11] 0[11:11] 0[11:11] 0[11:11] 0[11:11]

0[11:11] 0[11:11] 0[11:11] 0[11:11] 0[11:11]

2[13:13] 2[13:13] 2[13:13] 2[13:13] 2[13:13]

2[13:13] 2[13:13] 2[13:13] 2[13:13] 2[13:13]

Тестовые потоки запускаются с приоритетами 11, 12, 13, а запускающий поток имеет приоритет 10.

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

Во втором случае — взаимное блокирование на мютексе. Поток 0 начинает выполняться, «почувствовав» блокирование со стороны 2, под приоритетом ожидающего потока 2 ([11:13]), вытесняет поток 1. Затем, освободив мютекс, передает управлению потоку 2, после его завершения потоку 1. это наследование приоритетов, препятствующее возникновению инверсии приоритетов.

В третьем случае - блокирование на семафоре. Здесь потоки выполняются в таком порядке: 1-0-3 — это инверсия приоритетов.

А вот краткий вывод того же самого:

repeating number = 100000, debug level = 1

222222222211111111110000000000

repeating number = 100000, debug level = 1, lock on mutex

000000000012222222222111111111

repeating number = 100000, debug level = 1, lock on semaphore

111111111100000000002222222222

Теперь если запустить немного измененный код этой программы для Windows, то получим следующее:

repeating number = 50000000, no priority

012210210210210102102102102102

repeating number = 50000000

210222222222111111111000000000

repeating number = 50000000, lock on mutex

101111111110000000002222222222





Особенности написания прикладных программ под QNX


Тут либо тупо код(вряд ли), либо просто текст из книжки об особенностях.

Заключение





Добавить документ в свой блог или на сайт

Похожие:

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

Российской федерации
Целями освоения дисциплины «Системы реального времени» являются обучение студентов систематизированному представлению о базовых принципах...

Российской федерации
Целями освоения дисциплины «Системы реального времени» являются обучение студентов систематизированному представлению о базовых принципах...

Курсовая работа по дисциплине “Операционные системы” разработка ролевой компьютерной игры
Данная курсовая работа посвящена разработке компьютерной игры на движке «rpg maker xp», включая, в частности, разработку анимаций...

Курсовая работа по дисциплине «Сети ЭВМ и Средства Телекоммуникаций»
Данная курсовая работа посвящена организации потокового вещания видео в браузер средствами html5

Курсовая работа по дисциплине «Сети ЭВМ и Средства Телекоммуникаций»
Данная курсовая работа посвящена организации потокового вещания видео в браузер средствами html5

Курсовая работа по дисциплине «Операционные Системы»
Написанная программа организовывает взаимодействие между ядром операционной системы, от которого поступают запросы, субд, управляющей...

Курсовая работа По дисциплине «Сети эвм» На тему: «Анализ и оптимизация домашней лвс»
Основанием для разработки является учебный план по специальности 230105 «Программное обеспечение вычислительной техники и автоматизированных...

Курсовая работа По дисциплине «Сети эвм» На тему: «Анализ и оптимизация домашней лвс»
Основанием для разработки является учебный план по специальности 230105 «Программное обеспечение вычислительной техники и автоматизированных...

Отчет по лабораторной работе №1 по дисциплине «Безопасность вычислительных сетей»
Кафедра комплексной информационной безопасности электронно-вычислительных систем (кибэвс)

Вы можете разместить ссылку на наш сайт:
Школьные материалы


При копировании материала укажите ссылку © 2013
контакты
odtdocs.ru
Главная страница