15. Опишите дисциплины обслуживания прерываний.

Программное управление специальными регистрами маски (маскиро­вание сигналов прерывания) позволяет реализовать различные дисциплины обслуживания:

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

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

по принципу стека, или, как иногда говорят, по дисциплине LСFS (lаst соmе first sегvеd - последним пришел - первым обслужен), то есть запросы с более низким приоритетом могут прерывать обработку прерывания с более высоким приоритетом. Дли этого необходимо не накладывать маски ни на один сигнал прерывания и не выключать систему прерываний.

//Фул инфа 38-40 страницы

16. Охарактеризуйте однопроцессорную и распределенную архитектуры

Распределенные системы (distributed systems). По своей природе они больше подходят для управления сложными процессами. К основным преимуществам распределенных систем относятся:

- экономичность;

- надежность (при отказе нескольких процессоров остальные продолжают работать);

- возможность подобрать аппаратные средства в соответствии с конкретными требованиями.

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

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

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

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

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

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

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

Модель "клиент-сервер" основана на обмене сообщениями между программами. Если клиент и сервер исполняются на разных ЭВМ, а сообщения передаются через сеть, то система является распределенной.

Чем больше вычислительные ресурсы процедур клиента и сервера и чем больше сложных функций они могут выполнять независимо, тем меньше число сообщений и, соответственно, нагрузка на сеть. Фактически важным преимуществом распределенных систем является то, что ресурсоемкие вычисления можно выполнять локально и в результате уменьшить объем трафика, поскольку передается только информация, относящаяся к более высокому абстрактному уровню, чем локальные вычисления, то ecть некоторый итог локальных операций. Иными словами, в хорошо спроектированной системе сообщения содержат информацию о цели ("установить опорное значение х = 78.2"), а не о том, какие шаги следует для этого предпринять ("каково значение х в данный момент?", "х = 63", "увеличить на 16", "каково х сейчас?", "х = 79", уменьшить на 1", и т. д.). Промежуточные шаги выполняются локально при условии, что программное обеспечение спроектировано соответствующим образом.