учебники, программирование, основы, введение в,

 

Операционная среда

Из множества человеко-машинных систем мы более подробно рассмотрим так называемые операционные среды (или операционные системы) - системы общего назначения, предоставляющие пользователю возможность решать самые разнообразные задачи. Термин "операционная система (ОС)" обычно возникает в рассмотрении системы с точки зрения разработчика; нас же интересует прежде всего точка зрения пользователя, поэтому мы будем употреблять менее распространенный термин "операционная среда (ОС)". В проективной системе нет принципиальной разницы между этими двумя "ОС", но есть разница количественная: нас будет интересовать устройство прежде всего тех инструментов, которыми предстоит пользоваться (включая саму систему, разумеется). Знания устройства частей системы, которые работают "сами по себе" можно почерпнуть из документации и из книг, посвященных операционным системам.
Операционная среда - это совокупность инструментов, методов их интеграции и приемов работы с ними, позволяющая решать любые задачи в инструментальной области и большинство задач в прикладных областях. Отличие операционной среды от специализированной (например, статистического пакета SPSS) состоит в том, что, во-первых, в операционной среде есть средства решения задач во многих прикладных областях (а не в одной), а во-вторых, если инструмента решения какой-то задачи нет, то средствами операционной среды его всегда можно создать. Здесь мы окончательно отождествляем машину и компьютер, причем не просто микропроцессор, а компьютер общего назначения, обладающий развитой системой ввода, вывода, хранения и переработки информации. Только такой мощный инструмент, как компьютер, может служить платформой для построения системы, способной выполнять задачи из различных сфер деятельности человека.
Ресурсы и задачи
Основное назначение операционной среды - управлять ресурсами компьютера. Различают системные (инструментальные) и пользовательские (прикладные) ресурсы. Системные ресурсы - низкоуровневые, это та "расходная статья", которую согласовывают система и машина. Время работы процессора, оперативная память, память на постоянных носителях, возможности разнообразных внешних устройств и время их работы - все это система должна предоставлять пользователям, если потребуется, и про себя не забывать! Причем пользователи в своих решениях часто оперируют высокоуровневым, прикладным понятием ресурса. Пользовательские ресурсы - это требования к системе, выраженные в терминах объектов или функциональностей прикладной области. Это может быть файл или таблица, окно для рисования в графической системе, документ в системе печати, мелодия в динамике, запущенное задание, массив в памяти и т. п. В проективной системе пользователь должен понимать, в какие системные ресурсы преобразуются его прикладные запросы, чтобы оптимально проектировать их.
Часто бывает, что для представления пользовательского ресурса подходит системный (например, файл в качестве хранилища данных). Однако в общем случае каждому пользовательскому ресурсу должна соответствовать определенная системная модель, объединяющая несколько системных ресурсов и задающая правила их использования. Чем сложнее и дальше от системы такая модель, тем больше так называемая паразитная нагрузка на систему (overhead). Если решение спроектировано так, что паразитная нагрузка изначально больше полезной (payload), то при усложнении или увеличении мощности проекта ресурсопотребление может превзойти все нормы. Предположим, программа перекодировки написана так, что весь перекодируемый файл целиком размещается в оперативной памяти. Тогда с небольшими файлами такая программа будет работать очень быстро, потому что количество операций чтения/записи на диск будет минимальным, а вот с такими, размер которых сопоставим с объемом всей оперативной памяти, замысел пользователя пойдет насмарку. Когда общий объем данных превысит определенный порог, система организует интенсивную выгрузку и подгрузку страниц памяти все на тот же диск.
Задача в ОС - это объект системы, выполняющий системные или прикладные функции и потребляющий системные ресурсы; чаще всего считается, что задачи принадлежат какому-нибудь пользователю системы или ей самой. В зависимости от важности для ОС, задаче может быть выделено определенное количество ресурсов каждого вида. Иными словами, управление ресурсами рассматривается как их закономерное распределение между задачами и самой системой. (Не следует смешивать "важность для системы" и "важность для компьютера". Первое означает, что важная задача помогает системе производить качественный продукт, а второе вообще ничего не означает, потому что компьютеру все безразлично). ОС не имеет понятия о том, какими именно пользовательскими ресурсами оборачиваются те или иные запросы на выделение системных ресурсов. Зато известно обратное: какими системными ресурсами представлен объект. Предсказывать загруженность системы - дело пользователя, а точнее - разработчика модели прикладного ресурса. Например, почтовый ящик можно представлять в виде одного файла, в виде каталога с файлами-письмами, в виде нескольких каталогов с файлами-письмами, файлами-заголовками и т. д.; система отлично справится с любым представлением, но у каждого из них есть свои особенности.
Прежде всего необходимо, чтобы одинаковые для пользователя и системы, но разные с точки зрения реализации ресурсы управлялись бы одинаково. Например, системе должно быть безразлично, жесткий диск какой именно марки используется для создания файловой системы, какая именно структура файловой системы используется для хранения конфигурационного файла, а если он уже открыт и надо считать из него очередной блок - как именно он назывался и в какой файловой системе находился. Пользовательскому приложению не обязательно знать, как работать с регистрами различных графических или звуковых карт, если всего-то и нужно, что попищать и нарисовать квадратик. Значит, ОС нужно обеспечить унификацию интерфейса (способа обращения) к ресурсам и отделить интерфейс от реализации этого обращения.
Если выясняется, что некоторым ресурсом системы (например, файлами в файловой системе) пользоваться удобно, никто не хочет упускать такую возможность. Поэтому вторая функция ОС - разделение ресурсов. Системе необходимо сделать так, чтобы несколько задач могли пользоваться любым ресурсом, не мешая друг другу. Интерфейс ресурса определяется особой политикой разделения. Действовать в обход этой политики - значит использовать внесистемные средства доступа, что в идеальных ОС невозможно.

Время как системный ресурс
Главный системный ресурс, разделять который необходимо с наименьшей паразитной нагрузкой, - машинное время. Самый простой способ разделения времени - пакетное выполнение задач. Каждой задаче отводится некоторый промежуток машинного времени, в течение которого она обязана запуститься, отработать и завершиться. Если задача завершилась до истечения отведенного ей времени, запускается следующая. Если не успела завершиться, ее выполнение прерывается (навсегда), о чем пользователь получает уведомление, и опять-таки запускается следующая задача. Затраты на работу самой системы здесь минимальны (запустить, прервать), значит, почти все время будут работать пользовательские задачи. Казалось бы, большей эффективности добиться нельзя. В то же время для организации операционной среды этот способ крайне неудобен.
Во-первых, не все задачи одинаково занимают процессорное время. Многие потребляют временных ресурсов гораздо больше других: например, обмениваясь данными с медленными внешними устройствами. Такие задачи называют обменными, а задачи, загружающие в основном процессор, - счетными. И если бы было в системе средство дать процессору поработать, пока обменная задача ожидает окончания операции ввода/вывода, а также средство грамотно спланировать запуск этих задач, то эффективность системы возросла бы вдвое! Логику и политику планирования реализует планировщик задач (scheduler).
Во-вторых, есть обширный подкласс обменных задач, которые вообще почти ничем не занимаются, зато запускать их можно не когда угодно, а только в рабочее время. Это интерактивные задачи, то есть задачи, проводящие все свое время в диалоге с пользователем. Интерактивны текстовые редакторы, диалоговые системы, вообще любые приложения, в которых часто приходится спрашивать что-нибудь у пользователя и подолгу ждать ответа. Но главное в другом. Предположим, пришло десять пользователей системы, и все они запустили по интерактивной задаче, причем каждый желает, чтобы обслуживали именно его. На что имеет право, потому что одна обменная задача потребует секунду процессорного времени, но работа с ней займет у пользователя пять минут. Стало быть, грамотно устроенная ОС могла бы обслуживать этих пользователей, причем так, чтобы они не мешали друг другу. Оставшиеся 96% процессорного времени можно по ходу дела отдавать другим задачам. Здесь нужно использовать другой способ разделения времени - псевдопараллелизм (многозадачность, multitasking).
В самой упрощенной форме (за более подробными сведениями обращайтесь к или , здесь мы стараемся изложить лишь идею алгоритма) псевдопараллелизм выглядит так. Поскольку процессор на самом деле один (даже если не один, это ничего не меняет; другое дело, если бы процессоров было сколько угодно!), то и задача в каждый момент времени выполняется на нем одна. Но выполняется недолго, скажем, десятую долю секунды. После этого состояние задачи записывается куда-нибудь в системную память, а сама задача встает последней в очередь задач, готовых к выполнению. Вместо нее немножко работает первая задача в этой очереди, потом и с ней происходит то же самое, и т. д. Когда очередь опять доходит до исходной задачи, ее состояние восстанавливается и она продолжает работу как ни в чем не бывало. Состоянием (или контекстом) задачи называется информация, необходимая для того, чтобы задача продолжала работать как ни в чем не бывало: значение регистров процессора, место, где было прервано выполнение, собственные часы, табличка использования оперативной памяти и пр. Практически все компьютерные архитектуры имеют встроенные команды процессора, позволяющие аппаратно сохранять и восстанавливать контекст задачи.
Виртуальная память
Еще один механизм, обычно тоже реализованный аппаратно, связан с распределением памяти между задачами и называется механизмом виртуальной памяти (см.или ). Суть его в том, что оперативная память, заказанная любой задачей у системы на разных этапах работы (допустим, 8 Мбайт в сумме), доступна этой задаче по непрерывным адресам, начиная с 0 и заканчивая границей заказанного объема (последним адресом 8 Мбайт, 8388607). Это означает, что каждая задача использует свое адресное пространство, и адрес 0 в памяти одной задачи не соответствует адресу 0 в памяти другой. Если задаче потребуется еще 4 Мб, то этот кусок памяти будет адресоваться с 8388608 до 12582911. При этом, поскольку "настоящая", физическая оперативная память на всех одна, последний кусок в ней может располагаться совсем не рядом с первым. Физические адреса входящих в него ячеек памяти будут, конечно, совсем другими. Предыдущие 8 Мбайт тоже могут состоять из нескольких кусков, разбросанных по физической памяти.
Делается это с помощью таблиц преобразования адресов (они входят в контекст процесса), в которых написано, какого размера страницы памяти выделены этой задаче и где они на самом деле лежат. Механизм виртуальной памяти предполагает, что центральный процессор умеет работать в двух режимах: в режиме пользователя (user mode), когда вся адресация идет через таблицу преобразования, и в режиме супервизора (или режиме ядра, supervisor или kernel mode), когда вся адресация идет напрямую. Кроме того, только в режиме супервизора разрешены команды процессора, работающие с этими табличками, а также некоторые другие. Таким образом, задачи не могут изменить память друг друга, потому что не имеют даже способа выйти за пределы собственного виртуального адресного пространства.

Управление доступом
Разделение ресурсов, помимо всего прочего, предполагает ограничение доступа к ним. Некоторым задачам можно пользоваться, скажем, этим файлом, а некоторым - нельзя. Еще нужно ограничивать максимальный объем ресурса, доступного каждой задаче. Особенно аккуратно надо ограничивать потребление оперативной памяти: задача, захватившая ее всю, может помешать работе других задач и системы. Такое разделение и ограничение должно быть достаточно гибким и настраиваемым, чтобы не создавать сложности на пустом месте: если необходимо, чтобы конкретная задача заняла, вопреки общему правилу, весь ресурс, значит, должна быть возможность ей это разрешить. Разделение ресурсов - очень непростое дело, здесь не проходит тактика "отнять и поделить", то есть раздать поровну всем нуждающимся задачам, потому что в результате получится, что каждой задаче достанется ничтожно малая часть, с которой она ничего поделать не сможет, а система тем временем будет простаивать.
Отчасти помочь в этом может учет ресурсов. Учет делается не только для того, чтобы узнать, сколько и каких ресурсов потребила та или иная задача, но еще и для того, чтобы узнать сколько их потребил тот или иной пользователь. Если эти ресурсы были платными (например, время работы модема), есть повод выставить пользователю счет. Учет помогает выяснить действительные потребности задачи и предполагаемые возможности системы (каким количеством задач ее еще можно нагрузить). Проективная система не может существовать без механизмов учета, так как именно они дают пользователю представление о реальном состоянии системы.
Итак, функции операционной среды - унификация, разделение и учет системных ресурсов, а также планирование и сопровождение задач. Под словом "сопровождение" мы подразумеваем всевозможные средства разработки и организации взаимодействия задач, которые пользователи системы применяют для построения приложений.
Интерфейс
Главная функция ОС - способность сообщаться с пользователем. От того, как будет организовано общение машины с человеком (иными словами, интерфейс системы), зависит, насколько полно человек сможет пользоваться возможностями системы, а стало быть, и то, насколько эффективной будет его работа с системой, и то, насколько она будет комфортной. Интерфейс - это в самом деле лицо ОС, именно он создает первое впечатление о системе. Если интерфейс недостаточно функционален (не позволяет воспользоваться всеми возможностями системы) или утомителен для глаз, это может изрядно помешать в работе (особенно в проективных системах). Словом, разработкой способа общения человека с машиной должна заниматься целая группа специалистов, состоящая из авторов системы, психологов, специалистов по эргономике, врачей и т. д. Кроме того, во главе такой группы должен стоять некто, кому ведома суть расплывчатого и противоречивого понятия "удобство".
На практике, конечно, столько внимания интерфейсу не уделяется, поэтому идеал не только недостижим, но пока что и неразличим. Более того, будучи не в силах изменить интерфейс собственной системы, некоторые разработчики приступают к выправлению "интерфейса" пользователя: оказывается, проще "вправить мозги" всем, чем подстраиваться под каждого.
Если же все-таки считать, что машина создана для человека, а не наоборот, в их диалоге можно различить две "темы", два потока взаимодействия. Во-первых, команды, которые человек дает машине, и сообщения о происходящем в системе, которые он получает. Назовем это потоком управления. Во-вторых, человек командует машиной с целью получить от нее какие-то сведения и нередко сам передает машине информацию, необходимую для решения задачи. Назовем этот обмен данными потоком данных.
Данные и команды передаются от машины человеку и обратно с помощью средств ввода/вывода. С одной стороны, работу средств ввода/вывода надо организовать так, чтобы поток данных и поток управления по возможности, не пересекались. С другой стороны, организация отдельных средств ввода/вывода для данных и для управления редко бывает оправданной. Сверх того, было бы очень хорошо, чтобы интерфейс подходил именно той работе, которой будет заниматься пользователь. Однако если профиль будущей работы предсказать с грехом пополам возможно, то предугадать, какой именно способ взаимодействия с машиной пользователь назовет подходящим, очень трудно. Поэтому хороший (гибкий) интерфейс снабжается средствами настройки, манипулируя которыми человек может совершенствовать механизм взаимодействия с машиной по своему усмотрению.
Таким образом, вырисовывается приблизительная архитектура ОС:

  • менеджер ресурсов (унификация, разделение и учет);
  • планировщик задач (это тоже менеджер ресурсов, но он обособлен, потому что обособлено понятие задачи);
  • системное наполнение (функциональность, используемая системой);
  • пользовательское наполнение (то, что может понадобиться пользователю);
  • интерфейс (диалог с пользователем).

Системное и пользовательское наполнение, естественно, пересекаются, но смысл разделения понятен: инструментальная область и прикладная область.

 

 
На главную | Содержание | < Назад....Вперёд >
С вопросами и предложениями можно обращаться по nicivas@bk.ru. 2013 г.Яндекс.Метрика