Лекция 12. Интерфейсы ОС. Структуры ОС

Схема одинарного буфера может быть применена и при поточно-ориентированном вводе-выводе - построчно или побайтно.

Грубое, но очень показательное сравнение процессов при использовании одинарной буферизации и при ее отсутствии.

Предположим, что

Т - это время, необходимое для ввода одного блока,

С - время, необходимое для вычислений, выполняющихся между запросами на ввод данных.

Без буферизации общее время выполнения, приходящееся на один блок, будет равно Т + С.

При использовании одинарной буферизации время выполнения равно

мах[С, Т] + М,

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

Построчная буферизация применима, например, в неинтеллектуальных терминалах, где пользователь вводит данные построчно, завершая строки символом возврата каретки, сигнализируя об окончании строки; вывод на терминал происходит таким же образом - построчно. Другим примером может служить строчный принтер.

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

В случае построчного ввода-вывода буфер может быть использован для хранения одной строки.

Пользовательский процесс приостанавливается на время ввода, ожидая поступления целой строки.

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

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

Двойной буфер

Улучшить схему одинарной буферизации можно путем использования двух системных буферов.

В этом случае процесс выполняет передачу данных в один буфер (или считывание из него), в то время как операционная система освобождает (или заполняет) другой. Эта технология известна как двойная буферизация или сменный буфер.

Время выполнения при блочно-ориентированной передаче данных можно грубо оценить как mах[С, T].

Таким образом, если С < Т, то блочно-ориентированное устройство может работать с максимальной скоростью. Если же С > Т, то двойная буферизация избавляет процесс от необходимости ожидания завершения ввода-вывода. В любом случае достигается преимущество перед одинарной буферизацией. Это улучшение буферизации осуществляется за счет увеличения ее сложности.

При поточно-ориентированном вводе мы снова обращаемся к двум альтернативным режимам работы. Необходимость приостановления процесса при построчном выводе возникает только в том случае, если при выводе очередной строки оба буфера не пусты. При побайтовых операциях двойной буфер не имеет никакого преимущества перед одинарным буфером двойной длины. В обоих случаях используется модель производителя/потребителя.

Циклический буфер

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

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

Принципы построения интерфейсов ОС.
Интерфейс пользователя (рис. 1):

• интерфейс командной строки(UI)
• графический интерфейс(GUI)

Рис. 1. Интерфейс пользователя

Интерфейс прикладного программирования (API).

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

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

Варианты реализации API

1. Реализация функций API на уровне ОС.

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

Достигается наибольшая эффективность выполнения функций API (т.к. прикладная программа обращается непосредственно к ОС).

Недостаток: практически полное отсутствие переносимости не только кода результирующей программы, но и кода исходной программы.

Переносимости можно было бы добиться, если унифицировать функции API различных ОС.

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

Хорошо известным примером API такого рода может служить набор функций предоставляемых пользователю со стороны ОС типа Microsoft Windows – WinAPI (Windows API).

Даже внутри корпоративного API существует определенная несогласованность, которая несколько ограничивает переносимость программ между различными ОС типа Windows. Еще одним примером такого API можно считать набор сервисных функций ОС типа MS-DOS, реализованный в виде набора подпрограмм обслуживания программных прерываний.

2. Реализация функций API на уровне системы программирования.

Функции API предоставляются пользователю в виде библиотеки функций соответствующего языка программирования. Чаще всего это библиотека времени исполнения – RTL (run time library).

Эффективность будет несколько ниже, чем при непосредственном обращении к функциям ОС, т.к. библиотечная функция все равно выполняет обращения к функциям ОС.

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

Для каждой ОС будет требоваться свой код RTL

3. Реализация функций API с помощью внешних библиотек.

Функции API предоставляются пользователю в виде библиотеки процедур и функций, созданной сторонним разработчиком/

Эффективность наименьшая, т.к. внешняя библиотека обращается как к функциям ОС, так и к функциям RTL.

Стандартизация API

Как правило, API не стандартизированы. В каждом конкретном случае набор вызовов API определяется, прежде всего, архитектурой ОС и ее назначением.

Частным случаем попытки стандартизации API является внутренний корпоративный стандарт компании Microsoft, известный как WinAPI.

Он включает в себя следующие реализации: Win16, Win32s, Win32, WinCE.

С точки зрения WinAPI (в силу ряда идеологических причин - обязательный графический «оконный» интерфейс пользователя), базовой задачей является окно.

Таким образом, WinAPI изначально ориентирован на работу в графической среде. Однако базовые понятия дополнены традиционными функциями, в том числе частично поддерживается стандарт POSIX.

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

Таким примером может служить очень известный и, пожалуй, один из самых распространенных стандартов - стандарт POSIX. В этом стандарте перечислен большой набор функций, их параметров и возвращаемых значений. Стандартизированными, согласно POSIX, являются не только обращения к API, но и файловая система, организация доступа к внешним устройствам, набор системных команд

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

Платформенно-независимый интерфейс POSIX.

POSIX (Portable Operating System for Computer Environments) - платформенно независимый системный интерфейс для компьютерного окружения.

Это стандарт IEEE (Institute of Electrical and Electronical Engineers - американский Институт инженеров по электротехнике и радиоэлектронике).

Стандарт описывает системные интерфейсы для открытых ОС, в том числе оболочки, утилиты и инструментарии.

Помимо этого, согласно POSIX, стандартизованными являются:

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

Стандарт базируется на UNIX-системах, но допускает реализацию и в других ОС.

POSIX возник как попытка всемирно известной организации IЕЕЕ пропагандировать переносимость приложений в UNIX-средах путем разработки абстрактного, платформенно-независимого стандарта.

Однако POSIX не ограничивается только UNIX-системами; существуют различные реализации этого стандарта в системах, которые соответствуют требованиям, предъявляемым стандартом IEEE Standard 1003.1-1990 (POSIX.l).