Смертельный захват, инверсия во времени

Смертельный захват ( Deadlock ). В народе побочные проявления этой си­туации называются «зацикливание» или «зависание». А причина этого может быть достаточ­но проста – задачи не поделили ре­сурсы. Пусть, например, Задача А за­хватила ресурс клавиатуры и ждет, ког­да освободится ресурс дисплея, а в это время Задача В также хочет пообщать­ся с пользователем и, успев захватить ресурс дисплея, ждет теперь, когда ос­вободится клавиатура. В таких случаях рекомендуется придерживаться тактики «или все, или и ничего». Другим и словами, если задача не смогла получить все необходимые для дальнейшей работы ресурсы, она должна освободить всё, что уже захва­чено, и повторить попытку позже. Другим решением, которое уже упоминалось, является использо­вание серверов ресурсов.

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

Синхронизация задач с внешними событиями

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

1. Стремление обеспечить максималь­но быструю и детерминированную реакцию системы на внешнее собы­тие.

2. Старание добиться минимально возможных периодов времени, ког­да в системе запрещены прерывания.

3. Подпрограммы обработки прерыва­ний выполняют минимальный объ­ем функций за максимально корот­кое время. Это обусловлено несколь­кими причинами. Во-первых, не все ОС РВ обеспечивают возможность «вытеснения» во время обработки подпрограмм прерывания. Во-вто­рых, приоритеты аппаратных прерываний не всегда соответствуют приоритетам задач, с которыми они связаны. В-третьих, задержки с обра­боткой прерываний могут привести к потере данных.

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

Синхронизация во времени

Как правило, в ОС РВ задается эталон­ный интервал (квант) времени, кото­рый иногда называют тиком (Tick) и ко­торый используется в качестве базовой единицы измерения времени. Размерность этой единицы для разных ОС рв может быть разной, как, впрочем, раз­ными могут быть набор функций и ме­ханизмы взаимодействия с таймером. Функции по работе с таймером используют для приостановки выполнения за­дачи на какое-то время, для запуска за­дачи в определенное время, для относи­тельной синхронизации нескольких задач по времени и т.п. Если в программе для ОС РВ вы увидите операнд delay (50), то, скорее всего, это обозначает, что в этом месте задача должна прер­ваться (блокироваться), а через 50 мс возобновить свое выполнение, а точнее, перейти в состояние готовности. Все это время процессор не простаивает, а решает другие задачи, если таковые имеются. Множество задач одновре­менно могут запросить сервис таймера, поэтому если для каждого такого запро­са используется элемент в таблице вре­менных интервалов, то накладные рас­ходы системы по обработке прерыва­ний от аппаратного таймера растут пропорционально размерности этой таблицы и могут стать недопустимыми. Для решения этой проблемы можно вместо таблицы использовать связный список и алгоритм так называемого дифференциального таймера, когда во время каждого тика уменьшается только один счетчик интервала времени. Для точной синхронизации таймера вычислительной системы с астрономическим временем могут применять­ся специальные часы с подстройкой по радиосигналам точного времени или навигационные приемники GPS, кото­рые позволяют воспользоваться атом­ными часами на борту орбитальных космических аппаратов, запущенных по программе Navstar.

20. Linux реального времени.

Для задач реального времени сообщество разработчиков Linux активно применяет специальные расширения – RTLinux, KURT и UTIME, позволяющие получить устойчивую среду реального времени. RTLinux представляет собой систему «жесткого» реального времени, а KURT (KU Real Time Linux) относится к системам «мягкого» реального времени. Linux-расширение UTIME, входящее в состав KURT, позволяет добиться увеличения частоты системных часов, что приводит к более быстрому переключению контекста задач.

Проект KURT характеризуется минимальными изменениями ядра Linux и предусматривает два режима работы – нормальный (normal mode) и режим реального времени (real-time mode). Процесс, использующий библиотеку API-интерфейсов KURT, в любые моменты времени может переключаться между этими двумя режимами. Программный пакет KURT оформлен в виде отдельного системного модуля Linux – RTMod, который становится дополнительным планировщиком реального времени. Данный планировщик доступен в нескольких вариантах и может тактироваться от любого системного таймера или от прерываний стандартного параллельного порта. Программист может переключаться из одного режима в другой по событиям, либо в определенных местах программы. При переключении в режим РВ все процессы в системе «засыпают» до момента освобождения ветви процесса реального времени. Это довольно удобно при реализации задач с большим объемом вычислений, по своей сути требующих механизмов реального времени, например в задачах обработки аудио- и видеоинфо.

Стандартно такты планировщика RTMod задаются от системного таймера – время переключения контекста задач реального времени (time slice) равно 10 мс. Используя же KURT совместно с UTIME, можно довести время переключения контекста задач до 1 мс. Прерывания обрабатываются стандартным для ОС Linux образом – через механизм драйверов.

API-интерфейс KURT разделяется на две части – прикладную и системную. Прикладная часть позволяет программисту управлять поведением процессов, а системный API-интерфейс предназначен для манипулирования пользоват.процессами и программирования собственных планировщиков.

Простота использования KURT позволяет с максимальным комфортом программировать задачи, требующие как функций реального времени, так и всего многообразия API-интерфейса Unix. Использ-е «мягкого» РВ обычно подходит для реализации мультимедийных задач, а также при обработке разного рода потоков инфо, где критично время получения результата. Совершенно другой подход применен при реализации в Linux «жесткого» РВ.

20. Linux реального времени. [2]

 

RTLinux – это дополнение к ядру Linux, реализующее режим «жесткого» реального времени, которое позволяет управлять различными чувствительными ко времени реакции системы процессами. По сути дела, RTLinux – это операционная система, в которой маленькое ядро реального времени сосуществует со стандартным POSIX-ядром Linux.

Разработчики RTLinux пошли по пути запуска из ядра реального времени Linux-ядра как задачи с наименьшим приоритетом. В RTLinux все прерывания обрабатываются ядром реального времени, а в случае отсутствия обработчика реального времени — передаются Linux-ядру. Фактически Linux-ядро является простаивающей (idle) задачей операционной системы реального времени, запускаемой только в том случае, если никакая задача реального времени не исполняется. При этом на Linux-задачу накладываются определенные ограничения, которые, впрочем, для программиста прозрачны.

Для обмена данными между операционными системами реального времени и Linux могут использоваться следующие механизмы: разделяемые области памяти; псевдоустройства, предоставляющие возможность обмена данными с приложениями реального времени.

Ключевой принцип построения RTLinux – как можно больше использовать Linux и как можно меньше собственно RTLinux. Действительно, именно Linux заботится об инициализации системы и устройств, а также о динамическом выделении ресурсов. «На плечи» RTLinux ложится только планирование задач реального времени и обработка прерываний.

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

21. Операционные системы реального времени и Windows

Сегодня становится широко распространенным желание потребителей использовать Windows NT в СРВ. Для этого имеется ряд весомых, на первый взгляд, причин: Win32 API считается стандартом, а на его базе разработано огромное количество программ; графический интерфейс стал сегодня очень популярным; для NT имеется немало готовых решений для коммерческих применений; в среду NT включены многие виды средств разработки.

NT – многонитевая ОС, она позволяет вытеснение, что удовлетворяет одному из требований к ОСРВ.

2-ое требование к ОСРВ связано с тем, что диспетчеризация должна осуществляться по приоритетам. В Windows NT имеются два класса приоритетов: класс реального времени и динамический класс. Процессы в классе реального времени имеют фиксированный приоритет, менять который может лишь само приложение, тогда как приоритет процессов динамического класса может меняться диспетчером. Процесс имеет базовый уровень приоритета. Нить в процессе может иметь приоритет в диапазоне плюс/минус 2 около баз.ур-ня или один из двух крайних ур-ней класса (16 или 31 для реального времени). Очевидно, что гарантировать предсказуемость системы можно только при использ-и процессов первого класса.

Казалось бы, 2-е требование также удовлетворено. Но малое число возможных уровней препятствует реализации СРВ на базе NT. Больш-во соврем. ОС РВ позволяет иметь по крайней мере 256 различных ур-ней. Чем больше имеется ур-ней, тем более предсказуемо поведение системы. В Windows NT имеется только 7 различных ур-ней для нити в данном процессе. В рез-те многие нити будут выполняться с одинаковыми приоритетами и, как следствие, предсказуемость поведения системы будет посредственной.

В ОС РВ вызовы системы синхронизации (семафоры или критические секции) должны уметь управлять наследованием приоритетов. В Windows NT это невозможно, поэтому это требование к ОСРВ не удовлетворяется.

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

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

21. Операционные системы реального времени и Windows [2]

Разработчики расширений пошли двумя путями:

– использовали ядра классических операционных систем реального времени в качестве дополнения к ядру Windows NT. Таковы решения фирм "LP Eleknroniks" и "Radisys". В первом случае параллельно с Windows NT (на одном компьютере!) работает операционная система VxWorks, во-втором случае - InTime. Кроме того, предоставляется набор функций для связи приложений реального времени и приложений Windows NT. Технология использования двух систем на одном компьютере понятна - работу с объектом выполняет приложение реального времени, передавая затем результаты приложениям Windows NT для обработки, передачи в сеть, архивирования и пр.

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

Область применения расширений реального времени - большие системы реального времени, где требуется визуализация, работа с базами данных, доступ в интернет и пр.

22. Операционная система QNX.

ОС QNX была создана программистами компании QNX Software System Ltd. в 1981 году и с этого момента она заняла лидирующее место среди СРВ, существующих на тот момент на рынке. ОС QNX смогла занять лидирующее положение благодаря многим особенностям, присущим только ей.

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

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

Масштабируемость и эффективность, достигаемую оптимальным использованием ресурсов и означающую ее применимость для встроенных (embedded) систем. В каталоге /dev нет огромной кучи файлов, соответствующих ненужным драйверам. Драйверы и менеджеры можно запускать просто из командной строки. И удалять (кроме файловой системы J) динамически. Можно иметь только тот сервис или те модули, к-рые реально нужны, причем это не требует серьезных усилий и не порождает проблемы.

Расширяемость и надежность одновременно, поскольку написанный вами драйвер не нужно компилировать в ядро, рискуя вызвать нестабильность системы. Менеджеры ресурсов (сервис логического уровня) работают в кольце 3, при этом можно добавлять свои, не опасаясь за систему. Драйверы работают в кольце 1 и могут вызвать проблемы, но не фатального характера. Кроме того, их достаточно просто писать и отлаживать. Например, постоянная головная боль разработчиков драйверов для Linux – получение физически непрерывного блока памяти для DMA-устройств – устраняется просто и элегантно, через функцию mmap().

Быстрый сетевой протокол FLEET, прозрачный для обмена сообщениями, автоматически обеспечивающий отказоустойчивость, балансирование нагрузки и маршрутизацию между альтернативными путями доступа. Он не так универсален, как TCP/IP, но гораздо проще в использовании и эффективнее.

22. Операционная система QNX. [2]

Богатый выбор графических подсистем, включающий QNX Windows, X11R5 и Photon, что позволяет разработчикам выбирать ту, которая лучше подходит для их целей. Для типичных областей применения QNX традиционная система X11 слишком тяжеловесна, но система Photon, построенная на тех же принципах модульности, что и сама QNX, позволяет получить полнофункциональный GUI (типа Motif 2.0), работающий вместе с POSIX-совместимой ОС всего в 4 Мбайт памяти.

Недостатки:

– нет поддержки SMP;

– нет своппинга виртуальной памяти на диск;

– неэффективная и нестандартная поддержка нитей (threads);

– нет поддержки Java (как следствие предыдущего пункта);

– нет поддержки отображения файлов в память;

– многочисленные ограничения файловой системы;

– нет поддержки Unix - domain sockets;

– слабые средства разграничения и контроля доступа пользователей;

– отсутствие средств безопасности в рамках собственного сетевого протокола.

⇐ Предыдущая12345Следующая ⇒

Поделиться: