Курс лекций Лекция операционные системы операционная система комплекс программ, обеспечивающий выполнение других программ


ОПЕРАЦИОННАЯ СИСТЕМА РЕАЛЬНОГО ВРЕМЕНИ



Скачать 436.5 Kb.
Pdf просмотр
страница2/3
Дата14.04.2017
Размер436.5 Kb.
Просмотров1275
Скачиваний0
ТипКурс лекций
1   2   3
3. ОПЕРАЦИОННАЯ СИСТЕМА РЕАЛЬНОГО ВРЕМЕНИ
Операционная система реального времени, ОСРВ (Real-Time Operating System) - тип операционной системы. Это: 1)
Операционная система, в которой успешность работы любой программы зависит не только от её логической http://profbeckman.narod.ru/EVM
правильности, но и от времени, за которое она получила этот результат. Если система не может удовлетворить временным ограничениям, должен быть зафиксирован сбой в её работе; 2) Реальное время в операционных системах - способность операционной системы обеспечить требуемый уровень сервиса в определённый промежуток времени»; 3)
Операционная система, реагирующая в предсказуемое время на непредсказуемое появление внешних событий; 4)
Интерактивные системы постоянной готовности. В категорию ОСРВ их относят, исходя из маркетинговых соображений, и если интерактивную программу называют «работающей в реальном времени», то это лишь означает, что запросы от пользователя обрабатываются с задержкой, незаметной для человека.
Операционные системы реального времени бывают двух типов - системы жесткого реального времени и системы мягкого реального времени. Операционная система, которая может обеспечить требуемое время выполнения задачи реального времени даже в худших случаях, называется операционной системой жёсткого реального времени. Операционная система может обеспечить требуемое время выполнения задачи реального времени в среднем, называется операционной системой мягкого реального времени.
Системы жёсткого реального времени не допускают задержек реакции системы, так как это может привести к: потере актуальности результатов; большим финансовым потерям; авариям и катастрофам. Если не выполняется обработка критических ситуаций либо она происходит недостаточно быстро, система жёсткого реального времени прерывает операцию и блокирует её, чтобы не пострадала надёжность и готовность остальной части системы. Примерами систем жёсткого реального времени могут быть - системы управления бортового оборудования, системы аварийной защиты, регистраторы аварийных событий.
Системы мягкого реального времени характеризуются возможностью задержки реакции, что может привести к увеличению стоимости результатов и снижению производительности системы в целом. Примером может служить работа компьтерной сети. Если система не успела обработать очередной принятый пакет, это приведет к остановке на передающей стороне и повторной посылке (в зависимости от протокола). Данные при этом не теряются, но производительность сети снижается.
Основное отличие системам жёсткого и мягкого реального времени можно охарактеризовать так: система жёсткого реального времени никогда не опоздает с реакцией на событие, система мягкого реального времени - не должна опаздывать с реакцией на событие. Обозначим операционной системой реального времени такую систему, которая может быть использована для построения систем жёсткого реального времени. Это определение выражает отношение к ОСРВ как к объекту, содержащему необходимые инструменты, но также означает, что эти инструменты ещё необходимо правильно использовать.
Большинство программного обеспечения ориентировано на «мягкое» реальное время. Для подобных систем характерно: гарантированное время реакции на внешние события (прерывания от оборудования); жёсткая подсистема планирования процессов (высокоприоритетные задачи не должны вытесняться низкоприоритетными, за некоторыми исключениями); повышенные требования к времени реакции на внешние события или реактивности (задержка вызова обработчика прерывания не более десятков микросекунд, задержка при переключении задач не более сотен микросекунд)
Классическим примером задачи, где требуется ОСРВ, является управление роботом, берущим деталь с ленты конвейера. Деталь движется, и робот имеет лишь маленький промежуток времени, когда он может её взять. Если он опоздает, то деталь уже не будет на нужном участке конвейера, и следовательно, работа не будет сделана, несмотря на то, что робот находится в правильном месте. Если он подготовится раньше, то деталь ещё не успеет подъехать, и он заблокирует ей путь.
Табл. 1. Сравнение ОСРВ и обычных операционных систем.
ОС реального времени
ОС общего назначения
Основная задача
Успеть среагировать на события, происходящие на оборудовании
Оптимально распределить ресурсы компьютера между пользователями и задачами
На что ориентирована
Обработка внешних событий
Обработка действий пользователя
Как позиционируется
Инструмент для создания конкретного аппаратно- программного комплекса реального времени
Воспринимается пользователем как набор приложений, готовых к использованию
Кому предназначена
Квалифицированный разработчик
Пользователь средней квалификации
В своем развитии ОСРВ строились на основе следующих архитектур.
Монолитная архитектура. ОС определяется как набор модулей, взаимодействующих между собой внутри ядра системы и предоставляющих прикладному ПО входные интерфейсы для обращений к аппаратуре.
Основной недостаток этого принципа построения ОС заключается в плохой предсказуемости её поведения, вызванной сложным взаимодействием модулей между собой. http://profbeckman.narod.ru/EVM

Уровневая (слоевая) архитектура. Пример – MS-DOS. Прикладное ПО имеет возможность получить доступ к аппаратуре не только через ядро системы и ее сервисы, но и напрямую. По сравнению с монолитной такая архитектура обеспечивает значительно большую степень предсказуемости реакций системы, а также позволяет осуществлять быстрый доступ прикладных приложений к аппаратуре. Главным недостатком таких систем является отсутствие многозадачности.
Архитектура «клиент–сервер». Основной её принцип заключается в вынесении сервисов ОС в виде серверов на уровень пользователя и выполнении микроядром функций диспетчера сообщений между клиентскими пользовательскими программами и серверами – системными сервисами. Преимущества такой архитектуры: Повышенная надежность, т. к. каждый сервис является, по сути, самостоятельным приложением и его легче отладить и отследить ошибки; Улучшенная масштабируемость, поскольку ненужные сервисы могут быть исключены из системы без ущерба к ее работоспособности; Повышенная отказоустойчивость, т. к. «зависший» сервис может быть перезапущен без перезагрузки системы.
Табл. 2. Архитектуры операционных систем реального времени
Монолитная архитектура
Уровневая (слоевая) архитектура
Архитектура «клиент–сервер»
Ядро операционной системы обеспечивает функционирование промежуточного абстрактного уровня
ОС, который скрывает от прикладного ПО специфику технического устройства процессора (нескольких процессоров) и связанного с ним аппаратного обеспечения.
Указанный абстрактный уровень предоставляет для прикладного программного обеспечения пять основных категорий сервисов.
Управление задачами. Самая главная группа сервисов. Позволяет разработчикам приложений проектировать программные продукты в виде наборов отдельных программных фрагментов, каждый из которых может относиться к своей тематической области, выполнять отдельную функцию и иметь свой собственный квант времени, отведенный ему для работы. Каждый такой фрагмент называется задачей.
Сервисы в рассматриваемой группе обладают способностью запускать задачи и присваивать им приоритеты.
Основной сервис здесь - планировщик задач. Он осуществляет контроль за выполнением текущих задач, запускает новые в соответствующий период времени и следит за режимом их работы.
Динамическое распределение памяти. Многие (но не все) ядра ОСРВ поддерживают эту группу сервисов.
Она позволяет задачам заимствовать области оперативной памяти для временного использования в работе приложений. Часто эти области впоследствии переходят от задачи к задаче, и посредством этого осуществляется быстрая передача большого количества данных между ними. Некоторые очень малые по размеру ядра ОСРВ, которые предполагается использовать в аппаратных средах с строгим ограничением на объем используемой памяти, не поддерживают сервисы динамического распределения памяти.
Управление таймерами. Так как встроенные системы предъявляют жесткие требования к временным рамкам выполнения задач, в состав ядра ОСРВ включается группа сервисов, обеспечивающих управление таймерами для отслеживания лимита времени, в течение которого должна выполняться задача. Эти сервисы измеряют и задают различные промежутки времени (от 1 мкс и выше), генерируют прерывания по истечении временных интервалов и создают разовые и циклические будильники.
Взаимодействие между задачами и синхронизация. Сервисы данной группы позволяют задачам обмениваться информацией и обеспечивают ее сохранность. Они так же дают возможность программным фрагментам согласовывать между собой свою работу для повышения эффективности. Если исключить эти сервисы из состава ядра ОСРВ, то задачи начнут обмениваться искаженной информацией и могут стать помехой для работы соседних задач.
Контроль устройства ввода/вывола. Сервисы этой группы обеспечивают работу единого программного интерфейса, взаимодействующего со всем множеством драйверов устройств, которые являются типичными для большинства встроенных систем.
В дополнение к сервисам ядра, многие ОСРВ предлагают линейки дополнительных компонентов для организации таких высокоуровневых понятий, как файловая система, сетевое взаимодействие, управление http://profbeckman.narod.ru/EVM
сетью, управление базой данных, графический пользовательский интерфейс и т. д. Хотя многие из этих компонентов намного больше и сложнее, чем само ядро ОСРВ, они, тем не менее, основываются на его сервисах. Каждый из таких компонентов включается во встроенную систему, только если ее сервисы необходимы для выполнения встроенного приложения и только для того, чтоб свести расход памяти к минимуму.
Многие операционные системы общего назначения также поддерживают указанные выше сервисы.
Однако ключевым отличием сервисов ядра ОСРВ является детерминированный, основанный на строгом контроле времени, характер их работы. В данном случае под детерминированностью понимается то, что для выполнения одного сервиса операционной системы требуется временной интервал заведомо известной продолжительности. Теоретически это время может быть вычислено по математическим формулам, которые должны быть строго алгебраческими и не должны включать никаких временных параметров случайного характера. Любая случайная величина, определяющая время выполнения задачи в ОСРВ может вызвать нежелательную задержку в работе приложения, тогда следующая задача не уложится в свой квант времени, что послужит причиной для ошибки.
В этом смысле операционные системы общего назначения не являются детерминированными. Их сервисы могут допускать случайные задержки в своей работе, что может привести к замедлению ответной реакции приложения на действия пользователя в заведомо неизвестный момент времени. При проектировании обычных операционных систем разработчики не акцентируют свое внимание на математическом аппарате вычисления времени выполнения конкретной задачи и сервиса. Это не является критичным для подобного рода систем.
Большинство ОСРВ выполняют планирование задач, руководствуясь следующей схемой. Каждой задаче в приложении ставится в соответствие некоторый приоритет. Чем больше приоритет, тем выше должна быть реактивность задачи. Высокая реактивность достигается путем реализации подхода приоритетного вытесняющего планирования (preemptive priority scheduling), суть которого заключается в том, что планировщику разрешается останавливать выполнение любой задачи в произвольный момент времени, если установлено, что другая задача должна быть запущена незамедлительно. Описанная схема работает по следующему правилу: если две задачи одновременно готовы к запуску, но первая обладает высоким приоритетом, а вторая низким, то планировщик отдаст предпочтение первой. Вторая задача будет запущена только после того, как завершит свою работу первая. Возможна ситуация, когда задача с низким приоритетом уже запущена, а планировщик получает сообщение, что другая задача с более высоким приоритетом готова к запуску. Причиной этому может послужить какое-либо внешнее воздействие (прерывание от оборудования), как, например, изменение состояния переключатля устройства, управляемого ОСРВ. В такой ситуации планировщик задач поведет себя согласно подходу приоритетного вытесняющего планирования следующим образом. Задаче с низким приоритетом будет позволено выполнить до конца текущую ассемблерную команду (но не команду, описанную в исходнике программы языком высокого уровня), после чего выполнение задачи останавливается. Далее запускается задача с высоким приоритетом. После того, как она прорабатывает, планировщик запускает прерванную первую задачу с ассемблерной команды, следующей за последней выполненой.
Каждый раз, когда планировщик задач получает сигнал о наступлении некоторого внешнего события
(триггер), причина которого может быть как аппаратная, так и программная, он действует по следующему алгоритму: Определяет, должна ли текущая выполняемая задача продолжать работать; Устанавливает, какая задача должна запускаться следующей; Сохраняет контекст остановленной задачи (чтобы она потом возобновила работу с места останова); Устанавливает контекст для следующей задачи; Запускает эту задачу.
Эти пять шагов алгоритма также называются переключением задач. В обычных ОСРВ задача может находиться в 3-х возможных состояниях: Задача выполняется; Задача готова к выполнению; Задача заблокирована. Большую часть времени основная масса задач заблокирована. Только одна задача может выполняться на центральном процессоре в текущий момент времени. В примитивных ОСРВ список готовых к исполнению задач, как правило, очень короткий, он может состоять не более чем из двух-трех наименований. Основная функция администратора ОСРВ заключается в составлении такого планировщика задач. Если в списке готовых к выполнению задач последних имеется не больше двух-трех, то предполагается, что все задачи расположены в оптимальном порядке. Если же случаются такие ситуации, что число задач в списке превышает допустимый лимит, то задачи сортируются в порядке приоритета.
Для решения задачи эффективного планирования в ОСРВ наиболее интенсивно применяются два подхода: http://profbeckman.narod.ru/EVM

Статические алгоритмы планирования (RMS - Rate Monotonic Scheduling). Используют приоритетное вытесняющее планирование. Приоритет присваивается каждой задаче до того, как она начала выполняться.
Преимущество отдается задачам с самыми короткими периодами выполнения.
Динамические алгоритмы планирования (EDF - Earliest Deadline First Scheduling). Приоритет задачам присваивается динамически, причем предпочтение отдается задачам с наиболее ранним предельным временем начала (завершения) выполнения.
При больших загрузках системы EDF более эффективен, нежели RMS.
Многозадачным системам необходимо распределять доступ к ресурсам. Одновременный доступ двух и более процессов к какой либо области памяти или другим ресурсам представляет определённую угрозу.
Существует 3 способа решения этой проблемы: Временное блокирование прерываний; Двоичные семафоры;
Посылка сигналов. ОСРВ обычно не используют первый способ, потому что пользовательское приложение не может контролировать процессор столько, сколько хочет. Однако, во многих встроенных системах и
ОСРВ позволяется запускать приложения в режиме ядра для доступа к системным вызовам и дается контроль над окружением исполнения без вмешательства ОС.
На однопроцессорных системах наилучшим решением является приложение запущенное в режиме ядра, которому позволено блокирование прерываний. Пока прерывание заблокировано приложение использует ресурсы процесса единолично, никакая другая задача или прерывание не может выполнятся.
Таким образом защищаются все критичные ресурсы. После того как приложение завершит критические действия, оно должно разблокировать прерывания, если таковые имеются. Временное блокирование прерывания позволено только тогда, когда самый долгий промежуток выполнения критической секции меньше, чем допустимое время реакции на прерывание. Обычно этот метод защиты используется только когда длина критического кода не превышает нескольких строк и не содержит циклов. Этот метод идеально подходит для защиты регистров. Когда длина критического участка больше максимальной или содержит циклы, программист должен использовать механизмы идентичные или имитирующие поведение систем общего назначения, такие как семафоры и посылка сигналов.
Следующим проблемам выделения памяти в ОСРВ уделяется больше внимания, нежели в операционных системах общего назначения: 1) Скорост выделения памяти. Стандартная схема выделения памяти предусматривает сканирование списка неопределенной длины для нахождения свободной области памяти заданного размера, а это неприемлемо, так как в ОСРВ выделение памяти должно происходить за фиксированное время. 2) Память может стать фрагментированной в случае разделения свободных ее участков уже запущенными процессами. Это может привести к остановке программы из-за её неспособности задействовать новый участок памяти. Алгоритм выделения памяти, постепенно увеличивающий фрагментированность памяти, может успешно работать на настольных системах, если те перезагружаются не реже одного раза в месяц, но является неприемлемым для встроенных систем, которые работают годами без перезагрузки. Простой алгоритм с фиксированной длиной участков памяти очень хорошо работает в несложных встроенных системах. Также этот алгоритм отлично функционирует и в настольных системах, особенно тогда, когда во время обработки участка памяти одним ядром следующий участок памяти обрабатывается другим ядром. Такие оптимизированные для настольных систем ОСРВ как Unision Operating
System или DSPnano RTOS предоставляют указанную возможность.
К операционным системам реального времени относятся: Свободные (XOberon, RTLinux, RTEMS, eCos,
Fiasco, OSA, FreeRTOS, KURT, Phoenix-RTOS, Nut/OS, Prex, RTAI, scmRTOS, SHaRK, TRON Project, Xenomai,
BeRTOS), Проприетарные (Automation Runtime, QNX, RTOS-32, Ardence RTX, ChorusOS, DNIX, DMERT, DSOS,
embOS (Segger), HP-1000/RTE, INTEGRITY, ITRON, LynxOS, MERT, MicroC/OS-II, MQX RTOS, Nucleus, OS-9,
OSE, OSEK/VDX, OSEKtime, PDOS, Phar Lap ETS, PikeOS, Portos, pSOS, REX, RMX, RSX-11, RT-11, RTOS-UH,
RTXC, Salvo RTOS, SINTRAN III, Symbian OS, ThreadX, VRTX, VxWorks/Tornado, Windows CE, µnOS, UNIX-
RTR, Virtuoso, DSP, eCos, Багет).
Операционные системы могут быть классифицированы по базовой технологии (UNIX-подобные, пост-
UNIX/потомки UΝΙΧ), типу лицензии (проприетарная или открытая), развивается ли в настоящее время
(устаревшие или современные), по назначению (универсальные, ОС встроенных систем, ОС PDA, ОС реального времени, для рабочих станций или для серверов), а также по множеству других признаков.
4. НЕКОТОРЫЕ ОПЕРАЦИОННЫЕ СИСТЕМЫ
4.1 UNIX
UNIX - группа переносимых, многозадачных и многопользовательских операционных систем..
Первая система UNIX разработана в 1969 в подразделении Bell Labs компании AT&T. С тех пор было создано большое количество различных UNIX-систем. Юридически лишь некоторые из них имеют полное http://profbeckman.narod.ru/EVM
право называться «UNIX»; остальные же, хотя и используют сходные концепции и технологии, объединяются термином «UNIX-подобные».
Некоторые отличительные признаки UNIX-систем включают в себя: использование простых текстовых файлов для настройки и управления системой; широкое применение утилит, запускаемых в командной строке; взаимодействие с пользователем посредством виртуального устройства - терминала; представление физических и виртуальных устройств и некоторых средств межпроцессового взаимодействия как файлов; использование конвейеров из нескольких программ, каждая из которых выполняет одну задачу.
В настоящее время UNIX используются в основном на серверах, а также как встроенные системы для различного оборудования. На рынке ОС для рабочих станций и домашнего применения UNIX уступили другим операционным системам, таким как Microsoft Windows и Mac OS, хотя существующие программные решения для Unix-систем позволяют реализовать полноценные рабочие станции как для офисного, так и для домашнего использования.
UNIX-системы имеют большую историческую важность, поскольку благодаря им распространились некоторые популярные сегодня концепции и подходы в области ОС и программного обеспечения. Также, в ходе разработки Unix-систем был создан язык Си.
Коротко остановимся на истории создания UNIX
В 1957 в Bell Labs была начата работа по созданию операционной системы для собственных нужд. Под руководством Виктора Высотского создана система BESYS. Впоследствии он возглавил проект Multics, а затем стал главой информационного подразделения Bell Labs. В 1964 появились компьютеры третьего поколения, для которых возможности BESYS уже не подходили. UNIX была разработана сотрудниками Bell
Labs К. Томсоном, Д. Ритчи и Д. МакИлроем. В 1969 Кен Томпсон, стремясь реализовать идеи, которые были положены в основу MULTICS, но на более скромном аппаратном обеспечении (DEC PDP-7), написал первую версию новой операционной системы, а Брайан Кернинган придумал для неё название - UNICS (UNIplexed
Information and Computing System) - в противовес MULTICS (MULTIplexed Information and Computing Service).
Позже это название сократилось до UNIX. В 1971 вышла версия для PDP-11, наиболее успешного семейства миникомпьютеров 1970-х (в СССР оно было известно как СМ ЭВМ). Эта версия получила название «первая редакция» (Edition 1). Первые версии UNIX были написаны на ассемблере и не имели встроенного компилятора с языка высокого уровня. В 1969 К. Томпсон при содействии Д. Ритчи разработал и реализовал язык Би (B), представлявший собой упрощённый (для реализации на миникомпьютерах) вариант разработанного в 1966 языка BCPL. Би, как и BCPL, был интерпретируемым языком. В 1972 выпущена вторая редакция UNIX, переписанная на языке Би. В 1969—1973 на основе Би разработан компилируемый язык, получивший название Си (C). В 1973 вышла третья редакция UNIX, со встроенным компилятором языка Си. 15 октября того же года появилась четвёртая редакция, с переписанным на Си системным ядром, а в 1975 - пятая редакция, полностью переписанная на Си. С 1974 UNIX стал бесплатно распространяться среди университетов и академических учреждений. http://profbeckman.narod.ru/EVM

Рис. 1 . Генеалогическое древо UNIX-систем
С 1975 началось появление новых версий, разработанных за пределами Bell Labs, и рост популярности системы. Bell Labs выпустила шестую редакцию, известную по широко разошедшимся комментариям Джона
Лайонса. Седьмая редакция была последней единой версией UNIX. Именно в ней появился близкий к современному интепретатор командной строки Bourne shell. С 1978 начинает свою историю BSD UNIX, созданный в университете Беркли. В 1979 выпущена версия 3BSD ( седьмая редакция). BSD поддерживал такие свойства, как виртуальную память и замещение страниц по требованию (автор Б.Джой). В начале 1980- x компания AT&T, которой принадлежали Bell Labs, осознала ценность UNIX и начала создание коммерческой версии UNIX. Эта версия, поступившая в продажу в 1982, носила название UNIX System III и была основана на седьмой версии системы. Было предложено два интерфейса программирования сетевых приложений: Berkley sockets и интерфейс транспортного уровня TLI (Transport Layer Interface). Интерфейс
Berkley sockets разработан в университете Беркли и использовал стек протоколов TCP/IP. TLI был создан
AT&T в соответствии с определением транспортного уровня модели OSI и появился в системе System V версии 3. Реализация TCP/IP включена в базовую поставку System V версии 4. Это вызвало размежевание между двумя ветвями UNIX - BSD (университета Беркли) и System V (коммерческая версия от AT&T).
Впоследствии, многие компании, лицензировав System V у AT&T, разработали собственные коммерческие разновидности UNIX, такие, как AIX, CLIX, HP-UX, IRIX, Solaris.
В середине 1983 была выпущена версия 4.2BSD, поддерживающая работу в сетях Ethernet и Arpanet.
В 1983-1990 в BSD было добавлено много новых возможностей, причём существенно улучшены возможности работы с файловыми сетями. Тем временем AT&T выпускала новые версии своей системы, названной System V. В 1983 вышла версия 1 (SVR1 - System V Release 1). Версия 2 (SVR2, 1984), реализовывала монопольный доступ к файлам, доступ к страницам по требованию, копирование при записи.
Версия 3 вышла в 1987 и включала TLI, а также систему поддержки удалённых файловых систем RFS. Версия
4 (SVR4,1988), поддерживала многие возможности BSD, в частности TCP/IP, сокеты, новый командный интерпретатор csh. Современные реализации UNIX не являются системами V или BSD в чистом виде. Они реализуют возможности как System V, так и BSD.
В 1983 Р. Столлмэн объявил о создании проекта GNU - свободной UNIX-подобной операционной системы с нуля, без использования оригинального исходного кода. Большая часть программного обеспечения, разработанного в рамках данного проекта, - такого, как GNU toolchain, Glibc (стандартная библиотека языка Си) и Coreutils - играет ключевую роль в других свободных операционных системах.
Операционная система GNU и ядро Linux вместе составляют ОС, известную, как GNU/Linux. Дистрибутивы этой системы (такие как Red Hat и Debian), включающие ядро, утилиты GNU и дополнительное программное обеспечение стали популярными как среди любителей, так и среди представителей бизнеса. В 1992 вышел http://profbeckman.narod.ru/EVM
дистрибутив 386/BSD, основанный на Networking Release 2, распространяемый компанией BSDI. В 1993 появился другой дистрибутив - FreeBSD, нацеленный на простых пользователей. В 2005 был открыт исходный код операционной системы Solaris. Этот проект, как и созданная на его основе операционная система, получили название OpenSolaris. Затем был создан дистрибутив SchilliX. В 2008 появился первый официальный дистрибутив OpenSolaris 2008.05. Существует более десяти дистрибутивов на основе
OpenSolaris, наиболее известные из которых BeleniX и Nexenta OS. В настоящий момент GNU/Linux и представители семейства BSD быстро отвоёвывают рынок у коммерческих UNIX-систем и одновременно проникают как на настольные компьютеры конечных пользователей, так и на мобильные и встраиваемые системы.
После разделения компании AT&T, товарный знак UNIX и права на оригинальный исходный код неоднократно меняли владельцев, в частности, длительное время принадлежали компании Novell. В 1993
Novell передала права консорциуму X/Open, который затем объединился с Open Software Foundation, образовав консорциум The Open Group. Он объединяет ведущие компьютерные корпорации и государственные организации, в том числе IBM, Hewlett-Packard, Sun, NASA др. Консорциум занимается разработкой открытых стандартов в области операционных систем, самым важным из которых является
Single UNIX Specification, ранее известный как POSIX. В 1995 Novell продала права на лицензии и дальнейшую разработку System V компании Santa Cruz Operation. В 2000 Santa Cruz Operation продала свой
UNIX-бизнес компании Caldera, которая затем была переименована в SCO Group.
Идеи, заложенные в основу UNIX, оказали огромное влияние на развитие компьютерных операционных систем. Как и Multics, UNIX была написана на языке высокого уровня, а не на ассемблере
(доминировавшем в то время). Она содержала значительно упрощённую, по сравнению с современными ей операционными системами, файловую модель. Файловая система включала как службы, так и устройства
(такие как принтеры, терминалы и жёсткие диски) и предоставляла внешне единообразный интерфейс к ним, но дополнительные механизмы работы с устройствами не вписывались в простую модель «поток байтов».
UNIX популяризовала предложенную в Multics идею иерархической файловой системы с произвольной глубиной вложенности. Другие операционные системы того времени позволяли разбивать дисковое пространство на каталоги или разделы, но число уровней вложенности было фиксировано и уровень вложенности был только один. Позднее все основные фирменные операционные системы обрели возможность создания рекурсивных подкаталогов, заимствованную из Multics.
То, что интерпретатор команд стал просто одной из пользовательских программ, а в качестве дополнительных команд выступают отдельные программы, является ещё одной инновацией Multics. Язык командной оболочки UNIX используется пользователем как для интерактивной работы, так и для написания скриптов, т. е. не существует отдельного языка описания заданий, как, например, в системе JCL фирмы IBM.
Так как оболочка и команды операционной системы являются обычными программами, пользователь может выбирать их в соответствии со своими предпочтениями, или даже написать собственную оболочку. Наконец, новые команды можно добавлять к системе без перекомпиляции ядра. Предложенный в командной строке
UNIX, способ создания цепочек программ, последовательно обрабатывающих данные, способствовал использованию параллельной обработки данных.
Существенными особенностями UNIX были полная ориентация на текстовый ввод-вывод и предположение, что размер машинного слова кратен восьми битам. Первоначально в UNIX не было даже редакторов двоичных файлов - система полностью конфигурировалась с помощью текстовых команд.
Наибольшей и наименьшей единицей ввода-вывода служил текстовый байт, что полностью отличало ввод- вывод UNIX от ввода-вывода других операционных систем, ориентированного на работу с записями.
Ориентация на использование текста для представления всего, что только можно, сделала полезными т. н. конвейеры (pipelines). Ориентация на текстовый восьмибитный байт сделала UNIX более масштабируемой и переносимой, чем другие операционные системы. Со временем текстовые приложения одержали победу и в других областях, например, на уровне сетевых протоколов, таких как Telnet, FTP, SMTP, HTTP и других.
UNIX способствовала широкому распространению регулярных выражений, которые были впервые реализованы в текстовом редакторе ed для UNIX. Возможности, предоставляемые UNIX-программам, стали основой стандартных интерфейсов операционных систем (POSIX). Широко используемый в системном программировании язык Си, созданный изначально для разработки UNIX, превзошёл UNIX по популярности.
Си был первым «веротерпимым» языком, который не пытался навязать программисту тот или иной стиль программирования. Си был первым высокоуровневым языком, предоставляющим доступ ко всем возможностям процессора, таким как ссылки, таблицы, битовые сдвиги, приращения и т. п. С другой стороны, свобода Си приводила к ошибкам переполнения буфера в таких функциях стандартной библиотеки http://profbeckman.narod.ru/EVM

Си, как gets и scanf. Результатом стали многие печально известные уязвимости, например, та, что эксплуатировалась в знаменитом черве Морриса.
Первые разработчики UNIX способствовали внедрению принципов модульного программирования и повторного использоания в инженерную практику. UNIX предоставлял возможность использования протоколов TCP/IP на сравнительно недорогих компьютерах, что привело к быстрому росту Интерета. Это, в свою очередь, способствовало быстрому обнаружению нескольких крупных уязвимостей в системе безопасности, архитектуре и системных утилитах UNIX. Со временем ведущие разработчики UNIX разработали культурные нормы разработки программного обеспечения, которые стали столь же важны, как и сам UNIX
Особенности UNIX, отличающие данное семейство от других ОС: Файловая система древовидная, чувствительная к регистру символов в именах, очень слабые ограничения на длину имён. Нет поддержки структурированных файлов ядром ОС, на уровне системных вызовов файл есть поток байт. Командная строка находится в адресном пространстве запускаемого процесса, а не извлекается системным вызовом из процесса интерпретатора команд. Понятие «переменных окружения». Запуск процессов вызовом fork, т. е. возможность клонирования текущего процесса со всем состоянием. Понятия stdin/stdout/stderr. Ввод/вывод только через дескрипторы файлов. Традиционно крайне слабая поддержка асинхронного ввода/вывода, по сравнению с VMS и Windows NT. Интерпретатор команд есть обыкновенное приложение, общающееся с ядром обыкновенными системными вызовами. Команда командной строки есть не более чем имя файла программы, не требуется специальная регистрация и специальная разработка программ как команд. Не принят подход с программой, задающей пользователю вопросы о режимах своей работы, вместо этого используются параметры командной строки. Пространство имён устройств на диске в каталоге /dev, поддающееся управлению администратором, в отличие от подхода Windows, где это пространство имен размещается в памяти ядра, и администрирование этого пространства (например, задание прав доступа) крайне затруднено из-за отсутствия его постоянного хранения на дисках (строится каждый раз при загрузке).
Широкое использование текстовых файлов для хранения настроек, в отличие от двоичной базы данных настроек, как, например, в Windows. Широкое использование утилит обработки текста для выполнения повседневных задач под управлением скриптов. «Раскрутка» ОС после загрузки ядра путём исполнения скриптов стандартным интерпретатором команд. Широкое использование конвейеров (pipe). Все процессы, кроме init, равны между собой, не бывает «специальных процессов». Адресное пространство делится на глобальное для всех процессов ядро и на локальную для процесса части, нет «групповой» части адресного пространства, как в VMS и Windows NT, как и возможности загрузки туда кода и его исполнения там.
Использование двух уровней привилегий процессора вместо четырёх в VMS. Отказ от использования оверлеев в пользу деления программы на несколько программ поменьше, общающихся через конвейеры или временные файлы. Отсутствие APC и аналогов, то есть произвольных (а не жестко перечисленных в стандартном множестве) сигналов, не доставляемых до явного пожелания процесса их получить. Концепция сигнала уникальна для UNIX, и крайне сложна в переносе на другие ОС, такие, как Windows.
Большое количество разных вариантов системы UNIX привело к необходимости стандартизовать её средства, чтобы упростить переносимость приложений и избавить пользователя от необходимости изучать особенности каждой разновидности UNIX. С этой целью ещё в 1980 была создана пользовательская группа
/usr/group. Самые первые стандарты были разработаны в 1984-1985 гг. В настоящее время наиболее важными являются следующие стандарты: POSIX 1003.2-1992, определяющий поведение утилит, в том числе командного интерпретатора. POSIX 1003.1b-1993, дополняющий POSIX 1003.1-1988. Определяет поддержку систем реального времени. POSIX 1003.1c-1995, дополняющий POSIX 1003.1-1988. Определяет нити
(threads). Все стандарты POSIX объединены в документе IEEE 1003.
В начале 1990-х годов The Open Group предложила другой, похожий на POSIX стандарт - Common API
Specification, или Spec 1170. Стандарт приобрёл большую популярность, чем POSIX, поскольку был доступен бесплатно. В 1998 были начаты работы по объединению данных стандартов. Благодаря этому в настоящее время эти стандарты почти идентичны. Совместный стандарт называется Single UNIX Specification Version 3 и доступен бесплатно в интернете. В целях совместимости несколько создателей UNIX-систем предложили использовать ELF-формат систем SVR4 для двоичных и объектных файлов. Единый формат полностью обеспечивает соответствие двоичных файлов в рамках одной компьютерной архитектуры. Структура каталогов некоторых систем, в частности, GNU/Linux, определена в стандарте Filesystem Hierarchy Standard.



Поделитесь с Вашими друзьями:
1   2   3


База данных защищена авторским правом ©nethash.ru 2019
обратиться к администрации

войти | регистрация
    Главная страница


загрузить материал