Первое поколение (1945 – 1955): электронные лампы и коммутационные панели
Литература
1. Операционные системы: разработка и реализация (+CD). Классика CS /
Э. Таненбаум, А. Вудхалл. — СПб.: Питер, 2006. — С. 59–60.
2. Операционные системы: учебник для вузов /
А.В. Гордеев. — 2-е издание. — СПб.: Питер, 2004. — С. 279–289.
3. Операционные системы реального времени: методическое пособие /
Л.В. Калинин. — Ульяновск: «Инфофонд», 2009. — П.1.1.–1.3.
Модуль 1. АРХИТЕКТУРА ОПЕРАЦИОННЫХ СИСТЕМ
ТЕМА 1. ОСНОВНЫЕ ПОНЯТИЯ
Основные определения
Предметом настоящего обзора является отладка систем реального времени.
Под системой реального времени (СРВ) мы понимаем систему, в которой корректность функционирования зависит от соблюдения временных ограничений.
Система реального времени (СРВ) — это система, которая должна реагировать на события во внешней по отношению к системе среде или воздействовать на среду в рамках требуемых временных ограничений. Оксфордский словарь английского языка говорит о СРВ как о системе, для которой важно время получения результата. Другими словами, обработка информации системой должна производиться за определённый конечный период времени, чтобы поддерживать постоянное и своевременное взаимодействие со средой
Естественно, что масштаб времени контролирующей системы и контролируемой ей среды должен совпадать.
Под реальным временем понимается количественная характеристика, которая может быть измерена реальными физическими часами, в отличие от логического времени, определяющего лишь качественную характеристику, выражаемую относительным порядком следования событий. Говорят, что система работает в режиме реального времени, если для описания работы этой системы требуются количественные временны́е характеристики.
|
|
|
Характеристики систем реального времени
Процессы (задачи) систем реального времени могут иметь следующие характеристики и связанные с ними ограничения:
· дедлайн (англ. deadline) — критический срок обслуживания, предельный срок завершения какой-либо работы;
· латентность (англ. latency) — время отклика (время задержки) системы на внешние события;
· джиттер (англ. jitter) — разброс значений времени отклика. Можно различить джиттер запуска (англ. releasejitter) — период времени от готовности к исполнению до начала собственно исполнения задачи и джиттер вывода (англ. outputjitter) — задержка по окончании выполнения задачи. Джиттер может возникать под влиянием других, одновременно исполняемых задач.
В моделях систем реального времени могут фигурировать и другие параметры, например, период и количество итераций (для периодических процессов), нагрузка (англ. load) — количество команд процессора в худшем случае.
|
|
|
В зависимости от допустимых нарушений временных ограничений системы реального времени можно поделить на системы жёсткого реального времени, для которых нарушения равнозначны отказу системы, и системы мягкого реального времени, нарушения характеристик которых приводят лишь к снижению качества работы системы .
Следует заметить, что определение жёсткого реального времени ничего не говорит об абсолютном значении времени отклика: это могут быть как миллисекунды, так и недели. Требования к системам мягкого реального времени можно задать только в вероятностных терминах, например, как процент откликов, выданных в установленные временны́е рамки. Интересно, что при проектировании предварительные расчёты легче выполнить для системы жёсткого реального времени, чем получить, например, долю выполняемых в срок задач в системе мягкого реального времени, поэтому разработчики таких систем часто пользуются инструментами и методиками для проектирования систем жёсткого реального времени.
События реального времени
События реального времени могут относится к одной из трёх категорий:
· Асинхронные события — полностью непредсказуемые события. Например, вызов абонента телефонной станции.
|
|
|
· Синхронные события — предсказуемые события, случающиеся с определённой регулярностью. Например, вывод аудио и видео.
· Изохронные события — регулярные события (разновидность асинхронных), случающиеся в течение интервала времени. Например, в мультимедийном приложении данные аудиопотока должны прийти за время прихода соответствующей части потока видео.
Применение систем реального времени
С развитием технологий системы реального времени нашли применения в самых различных областях. Особенно широко СРВ применяются в промышленности, включая системы управления технологическими процессами, системы промышленной автоматики, SCADA-системы, испытательное и измерительное оборудование, робототехнике. Применения в медицине включают в себя томографию, оборудование для радиотерапии, прикроватный мониторинг. СРВ встроены в периферийные устройства компьютеров, телекоммуникационное оборудование и бытовую технику, такую как лазерные принтеры, сканеры, цифровые камеры, кабельные модемы, маршрутизаторы, системы для видеоконференций и интернет-телефонии, мобильные телефоны, микроволновые печи, музыкальные центры, кондиционеры, системы безопасности. На транспорте СРВ применяются в бортовых компьютерах, системах регулирования уличного движения, управлении воздушного движения, аэрокосмической технике, системе бронирования билетов и т. п. СРВ находят применения и в военной технике: системах наведения ракет, противоракетных системах, системах спутникового слежения.
|
|
|
Существующие СРВ являются многозадачными. Многозадачность реализуется через многопроцессность и многопоточность.
Многопроцессность в СРВ имеет существенные недостатки, поскольку требует поддержки времени выполнения для доступа к памяти, и, следовательно, при переключении контекстов системе нужно выполнить дополнительные действия.
Многопоточность — это наиболее распространенный подход при проектировании систем реального времени, при котором СРВ представляет собой один процесс, в рамках которого запущено несколько потоков.
Недостатком многопоточности является возможность модификации чужих данных какой-либо задачей (из-за отсутствия защиты). В связи с этим в СРВ представлены средства синхронизации, то есть средства, обеспечивающие задачам доступ к разделяемым ресурсам. К таким средствам относятся семафоры (бинарные и счетчики), мьютексы, очереди сообщений.
Структура СРВ приведена на рис. , где прикладной код — это совокупность пользовательских потоков управления, ОСРВ — операционная система реального времени, обеспечивающая планирование, синхронизацию и взаимодействие пользовательских потоков управления.
Рис. 1. Структура системы реального времени
Будем называть распределенную систему распределенной системой реального времени (РСРВ), если корректность ее функционирования зависит также и от ограничений, накладываемых на время обмена между компонентами системы.
Особенности отладки в системах реального времени
Отладка в СРВ направлена на обнаружение и исправление ошибок в прикладном коде. Она является одним из этапов кросс-разработки, схему которой можно представить следующим образом. Разработка приложения ведется как минимум на двух машинах: инструментальной и целевой. На инструментальной платформе происходит написание исходного текста, компиляция и сборка. На целевой — загрузка приложения, его тестирование и отладка.
Ввиду того, что целевая платформа, как правило, обладает более ограниченными ресурсами, чем инструментальная, отладка распределенных систем реального времени может быть двух видов.
Первый из них — имитация архитектуры целевой платформы, то есть возможность отладки целевых программных средств без использования самой платформы. Подобная имитация, как правило, не дает возможности провести подробное и полное тестирование ПО. Поэтому, такой тип отладки применяется только в случае отсутствия целевой платформы.
Второй способ — удаленная отладка (кросс-отладка). Кросс-отладка позволяет использовать ресурсы инструментальной системы при изучении поведения некоторого процесса в целевой системе.
Эффективность удаленной отладки зависит от типа связи инструментальной и целевой машин, а также от поддержки средств отладки со стороны целевой архитектуры.
Ключевым требованием к средствам отладки является возможность наблюдать и анализировать весь процесс выполнения отлаживаемых задач, а также системы в целом. В данной работе рассматриваются два метода отладки: активная отладка и мониторинг.
Суть активной отладки состоит в том, что отладчик имеет право останавливать выполнение задачи или всей системы, начинать или продолжать выполнение с некоторого адреса, отличного от точки останова, изменять значения переменных и регистров, и т.д. Недостаток этого метода заключается в том, что отладчик может вносить серьезные сбои в нормальную работу системы в связи с устанавливаемыми временными ограничениями. Этого можно избежать, остановив некоторую группу задач или всю систему целиком. Преимущество метода состоит в возможности корректировать поведение задачи в процессе ее выполнения.
Под мониторингом понимается сбор данных о задаче (значения регистров, переменных, и т. д.) или о системе в целом (стадии выполнения задач, происходящие события, и т. д.).
В процессе мониторинга отладчик практически не вмешивается в работу системы, обеспечивая нормальное ее функционирование, но вместе с тем не имеет возможности влиять на ход выполнения отлаживаемого приложения.
Ошибки в системах реального времени
Отмеченные выше методы отладки позволяют выявлять и устранять ошибки следующего характера:
1. Ошибки в программном обеспечении, влекущие неправильное выполнение задачи (безотносительно времени). Обычные ошибки, обнаруживаемые средствами активной отладки.
2. Ошибки в ОСРВ: ошибки планирования, синхронизации и связи. Для отладки, в этом случае, надо использовать один из способов мониторинга.
3. Логические ошибки, связанные с асинхронностью.
4. Ошибки, связанные с тем, что данные задачи были изменены другой задачей. Локализацию ошибок лучше проводить, используя мониторинг, а именно: осуществлять периодический контроль целостности данных, временно запрещать другим задачам доступ к некоторым участкам кода или данных.
ТЕМА 2. ИСТОРИЯ ОПЕРАЦИОННЫХ СИСТЕМ
Операционная система как менеджер ресурсов
Концепция, рассматривающая операционную систему, прежде всего, как удобный интерфейс пользователя — это взгляд сверху вниз. Альтернативный взгляд, снизу вверх, дает представление об операционной системе как о механизме, присутствующем в устройстве компьютера для управления всеми частями этой сложнейшей машины. Современные компьютеры состоят из процессоров, памяти, датчиков времени, дисков, мыши, сетевого интерфейса, принтеров и огромного количества других устройств. В соответствии со вторым подходом работа операционной системы заключается в обеспечении организованного и контролируемого распределения процессоров, памяти и устройств ввода / вывода между различными программами, состязающимися за право их использовать.
Что случилось бы, если бы на одном компьютере оказались работающими три программы, и все они одновременно попытались бы напечатать свои выходные данные на одном и том же принтере. Возможно, первые несколько строк на листе появились бы от первой программы, следующие несколько — из второй программы, затем бы следовало несколько строк от третьей программы и т. д. В результате получилась бы полная неразбериха. Операционная система наводит порядок в подобных ситуациях, буферизируя на диске все данные, предназначенные для печати. В процессе работы программы операционная система сохраняет ее выходные данные на диске во временном файле. Затем, по окончании работы этой программы, система отправляет данные на принтер, в то время как другая программа может продолжать формировать свои выходные данные, не обращая внимания на то, что они пока еще фактически не посылаются на печатающее устройство.
Когда компьютером (или сетью) пользуются несколько пользователей, необходимость в управлении памятью, устройствами ввода/вывода, другими ресурсами и их защите сильно возрастает, поскольку пользователи могут обращаться к ним в абсолютно непредсказуемом порядке. К тому же часто приходится распределять между пользователями не только оборудование, но и информацию (файлы, базы данных и т. д.). С этой точки зрения основная задача операционной системы заключается в отслеживании того, кто и какой ресурс использует, в обработке запросов на ресурсы, в подсчете коэффициента загрузки и разрешении проблем конфликтующих запросов от различных программ и пользователей.
История операционных систем
История развития операционных систем насчитывает уже много лет. Так как операционные системы появились и развивались в процессе конструирования компьютеров, то эти события исторически тесно связаны. Поэтому чтобы представить, как выглядели операционные системы, мы обсудим следующие друг за другом поколения компьютеров. Такая схема взаимосвязи поколений операционных систем и компьютеров довольно груба, но она обеспечивает некоторую структуру, без которой ничего не было бы понятно.
Первый настоящий цифровой компьютер был изобретен английским математиком Чарльзом Бэббиджем (Charles Babbage , 1792–1871). Хотя большую часть жизни Бэббидж посвятил попыткам создания своей «аналитической машины», он так и не смог заставить ее работать должным образом. Это была чисто механическая машина, а технологии того времени не были достаточно развиты для изготовления многих деталей и механизмов высокой точности. Не стоит и говорить, что его аналитическая машина не имела операционной системы.
Интересный исторический факт: Бэббидж понимал, что для аналитической машины ему необходимо программное обеспечение, поэтому он нанял молодую женщину по имени Ада Лавлейс (Ada Lovelace ), дочь знаменитого британского поэта Лорда Байрона. Она и стала первым в мире программистом, а язык программирования Ada ® назван в ее честь.
Первое поколение (1945 – 1955): электронные лампы и коммутационные панели
После неудачных попыток Бэббиджа вплоть до Второй мировой войны в конструировании цифровых компьютеров не было практически никакого прогресса. Примерно в середине 1940-х Говард Айкен (Howard Aiken ) в Гарварде, Джон фон Нейман (John von Neumann ) в Институте углубленного изучения в Принстоне, Дж. Преспер Эккерт (J . Presper Eckert ), Вильям Мочли (William Mauchley ) в Пенсильванском университете, Конрад Цузе (KonradZuse ) в Германии и многие другие продолжили работу в направлении создания вычислительных машин. На первых машинах использовались механические реле, но они были очень медлительны, длительность такта составляла несколько секунд. Позже реле заменили электронными лампами. Машины получались громоздкими, заполняющими целые комнаты, с десятками тысяч электронных ламп, но все равно они были в миллионы раз медленнее, чем даже самый дешевый современный персональный компьютер.
В те времена каждую машину и разрабатывала, и строила, и программировала, и эксплуатировала, и поддерживала в рабочем состоянии одна команда. Все программирование выполнялось на абсолютном машинном языке, управление основными функциями машины осуществлялось просто при помощи соединения коммутационных панелей проводами. Тогда еще не были известны языки программирования (даже ассемблера не было). Об операционных системах никто и не слышал. Обычный режим работы программиста был таков: записаться на определенное время на специальном стенде, затем спуститься в машинную комнату, вставить свою коммутационную панель в компьютер и провести несколько следующих часов в надежде, что во время работы ни одна из двадцати тысяч электронных ламп не выйдет из строя. Фактически тогда на компьютерах занимались только прямыми числовыми вычислениями, например расчетами таблиц синусов, косинусов и логарифмов.
К началу 50-х, с выпуском перфокарт, установившееся положение несколько улучшилось. Стало возможно вместо использования коммутационных панелей записывать и считывать программы с карт, но во всем остальном процедура вычислений оставалась прежней.
Дата добавления: 2018-08-06; просмотров: 632; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!