1) По возможности сохранить порядок окончания процессов таким, каков был порядок их запуска;

2) Отдавать предпочтение более коротким процессам;

3) Предоставлять всем пользователям одинаковые услуги (например, время ожидания).

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

Дисциплина диспетчеризации − правило, по которому формируют очередь готовых к выполнению задач. Существует два больших класса этих правил: бесприоритетные и приоритетные. Смысл первых правил − выбор задачи производится в заранее установленном порядке, без учёта их важности и времени обслуживания. Смысл вторых правил − отдельным задачам даётся преимущественное право (или приоритет) попасть в состояние исполнения. Приоритет задачи может быть величиной постоянной, либо может меняться в процессе её решения.

Классификация дисциплин диспетчеризации приведена на рис. 5:

Помимо деления согласно приведенной классификации дисциплины диспетчеризации делятся на:

1) Вытесняющие (preemptive), которым на выполнение вычислений выделяется квант процессорного времени, а в следующем кванте процессор передаётся другому процессу;

2) невытесняющие (non-preemptive), в которых текущий процесс занимает процессор в течение времени, необходимого для выполнения всех возможных вычислений, и только после этого передаёт его другому процессу.

Рассмотрим наиболее часто используемые дисциплины диспетчеризации.

Самая простая − дисциплина FCFS (first come – first served – первым пришёл первым обслужен), в соответствии с которой задачи обслуживаются в «порядке очереди». Заблокированные (или попавшие в состояние ожидания) задачи после перехода их в состояние готовности запускаются перед задачами, которые ещё не выполнялись.

3Десь как бы образуется две очереди: одна из новых задач, другая − из ранее выполнявшихся, но попавших в состояние ожидания.

Такой подход реализует первую стратегию обслуживания (т.е. «по возможности заканчивать вычисление в порядке их появления»). Эта дисциплина относится к невытесняющим. Ее достоинством является простота реализации и малый расход системных ресурсов на формирование очереди задач, а недостатком − возрастание среднего времени ожидания обслуживания, причем короткие задания вынуждены ждать почти столько же времени, что и трудоемкие задания (рис. 6).

Избежать этого недостатка позволяют дисциплины обслуживания SJN (Shortest Job Next или следующим будет выполняться кратчайшее задание) и SRT (Shortest Remaining Time или следующим будет выполняться задание, требующие меньше всего времени).

Для организации дисциплины SJN OC требуется информация о характеристиках задач, записываемая на некотором языке (например, на языке JCL – Job Control Language или язык управления заданиями). Пользователь должен указать предполагаемое время выполнения, а диспетчер задач сравнивает фактическое время с запрошенным на решение задачи и штрафует задачу, если расхождение между ними на некотором ресурсе было значительным (например, ставит ее в конец очереди).

При обслуживании в соответствии с дисциплиной SRT следующим на обработку подается задание, требующее меньшего времени на свое завершение. SJN и SRT относятся к невытесняющим дисциплинам обслуживания. Для интерактивных вычислений желательно чтобы были обеспечены приемлемое время реакции системы и равенство в обслуживании терминалов. Для этого случая наиболее подходящей является дисциплина обслуживания RR (Round Robin − круговая или карусельная). Эта дисциплина обслуживания предполагает, что каждой задаче выделяется квант процессорного времени q, в течение которого она владеет ресурсом. После чего задача снимается с ресурса − процессорного времени, ставится в конец очереди задач, готовых к выполнению. А ресурс передается следующему заданию из очереди (рис. 7). Это представитель вытесняющих дисциплин. Величина кванта времени выбирается как компромисс между приемлемым временем реакции системы на запросы пользователя и накладными расходами на частоту смены контекста задач. При большом q с ростом числа задач время реакции может сильно увеличиться, при малом − возрастёт частота переключений, появится необходимость в смене больших объёмов информации о процессах (текущие данные, дескрипторы процессов и т.д.), что также снижает производительность и время реакции системы. Как правило, в ОС для указания величины q используется диапазон значений, из которого выбирается оптимальное значение. Например, в файле CONFIG.SYS OS/2 c помощью оператора Timeslice=32,256 (переводится, как квант времени) указывается минимальное (32 мс) и максимальное (256 мс) допустимые значения q.

 Если при выбранном q некоторая задача была прервана, то следующий её квант будет увеличен на один период таймера (около 32 мс).

Организуется данная дисциплина достаточно просто: всем пользовательским задачам присваиваются одинаковые приоритеты и создается фиктивная задача с высоким приоритетом. Она запускается периодически по времени) указывается минимальное (32 мс) и время реакции системы и таймеру. Запускаясь, она прерывает активную задачу, а поскольку процессор ей не нужен, она сразу передаёт его очередной задаче. Снятая задача ставится в конец очереди.

Невытесняющая многозадачность (Non-preemptive multitasking). Это способ диспетчеризации, при котором активный процесс выполняется до тех пор, пока он сам не отдаст управление диспетчеру задач для выбора другого, готового к выполнению процесса или треда. Недостатком такого режима является то, что управление системой теряется на некоторый период времени, определяемый не системой, а процессом. «Недружественный» процесс может держать важнейший ресурс (процессорное время) недопустимо долго вплоть до зависания. Примером удачного использования невытесняющей многозадачности является сетевая ОС Novell NetWare, в которой благодаря этому достигнута высокая скорость выполнения файловых операций.

 Вытесняющая многозадачность (Preemptive multi-tasking) является выходом из этой ситуации. Это способ диспетчеризации, при котором задача выполняется небольшими частями, а по окончании выполнения части управление возвращается ОС. Достоинством такого подхода является то, что можно проектировать алгоритм распределения процессорного времени наиболее подходящий для данного фиксированного набора задач. Примером вытесняющей многозадачности может быть дисциплина RR.

47. Старатегія планування процесів і задач в операційних системах

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

47. Керування задачами і пам’яттю в операційних системах

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

Память является разделяемым ресурсом. Способы разделения памяти и времени центрального процессора сильно влияют на скорость выполнения отдельных вычислений и на общую эффективность вычислительной системы. ОС выполняет следующие основные функции, связанные с управлением задачами: - создание и удаление задач; - планирование процессов и диспетчеризация задач; - синхронизация задач, обеспечение их средствами коммуникации. Система управления задачами обеспечивает похождение их через компьютер. В зависимости от состояния процесса ему должен быть предоставлен тот или иной ресурс. Создание и удаление задач производится по соответствующим запросам от пользователей или самих задач. Основным подходом к организации того или иного метода управления процессами является организация очередей процессов и ресурсов. На распределение ресурсов влияют конкретные потребности тех задач, которые должны выполняться параллельно. Задачи динамического планирования, т.е. наиболее эффективного распределения ресурсов, возникающие практически при каждом событии, называются диспетчеризацией. Планирование осуществляется реже, чем задача текущего распределения ресурсов между уже выполняющимися процессами и потоками. Различие между долгосрочным и краткосрочным планированием заключается в частоте запуска. Краткосрочный планировщик решает, какая из задач, находящихся в очереди готовых к выполнению, должна быть передана на выполнение. В большинстве современных ОС долгосрочный планировщик отсутствует. Планирование и диспетчеризация процессов и задач Стратегия планирования Стратегия планирования (краткосрочное планирование, диспетчеризация) определяет, какие процессы планируются на выполнение для того, чтобы достигнуть поставленной цели. Стратегий планирования много, но основные из них следующие: - по возможности заканчивать вычисления в том же порядке, в котором он были начаты; - отдавать предпочтение более коротким задачам; - предоставлять всем пользователям одинаковые услуги, в том числе и одинаковое время ожидания. Стратегия планирования связана с понятием процесс, а не задача, так как процесс может состоять из нескольких задач (потоков). Свойства приоритетов: - приоритет, присвоенный задаче, может являться величиной постоянной; - приоритет задачи может изменяться в процессе ее решения. Диспетчеризация с динамическими приоритетами требует дополнительных расходов на вычисление значений приоритетов, поэтому многие ОС реального времени используют методы диспетчеризации на основе статических (постоянных) приоритетов. Самой простой в реализации является дисциплина FCFS (first come – first served), задачи обслуживаются в порядке очереди, т.е. в порядке их появления. Задачи, приостановленные для ожидания какого-либо ресурса, после перехода в состояние готовности становятся в эту очередь перед задачами, которые еще не выполнялись. Образуются две очереди: - новые задачи; - ранее выполнявшиеся, но попавшие в состояние ожидания. Дисциплина FCFS реализует стратегию обслуживания «по возможности заканчивать вычисления в порядке их появления». Эта дисциплина не требует внешнего вмешательства в ход вычислений и перераспределения процессорного времени. По классу диспетчеризации (вытесняющие и не вытесняющие) дисциплина FCFS относится к не вытесняющим. Достоинства дисциплины FCFS: - простота реализации; - малые расходы системных ресурсов на формирование очереди задач. Дисциплина обслуживания SJN (shortest job next) требует, чтобы для каждого задания была известна оценка в потребностях процессорного времени. Пользователи должны были указывать предположительное время выполнения. Диспетчер задач сравнивал указанное время с реальным временем выполнения и, если время выполнения превышало указанное, то помещал это задание в конец очереди. Дисциплина обслуживания SJN предполагает, что имеется только одна очередь заданий, готовых к выполнению. Если задание было временно заблокировано из-за занятости какого-либо ресурса, то оно помещается в конец очереди готовых к выполнению заданий наравне с вновь поступившими. Задания, которым требуется совсем немного времени для завершения, попадают в конец очереди. Для устранения этого недостатка была предложена дисциплина SRT (shortest remaining time, следующее задание требует меньше всего времени для своего завершения). Перечисленные три дисциплины обслуживания могут использоваться для пакетных режимов работы, когда не важно время отклика. Для интерактивной работы надо обеспечить приемлемое время реакции системы и равенство в обслуживании, если система мультитерминальная. Интерактивные задания должны иметь преимущество перед фоновыми. Эти условия решены в дисциплине RR (round robin – круговая, карусельная). Дисциплина обслуживания RR предполагает, что каждая задача получает процессорное время порциями (квантами). После окончания выделенного кванта времени задача снимается с исполнения и на выполнение выбирается следующая задача. Снятая задача помещается в конец очереди готовых к выполнению задач. Величина кванта времени выбирается как компромисс между приемлемым временем реакции системы на запросы пользователей и накладными расходами на частоту смены контекста задач. 51. Які бувають операційні системи за архітектурою Ядро и вспомогательные модули ОС

Наиболее общим подходом к структуризации операционной системы является разделение всех ее модулей на две группы:

•  ядро — модули, выполняющие основные функции ОС; 

•  модули, выполняющие вспомогательные функции ОС.

Ядро в привилегированном режиме

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

Многослойная структура ОС

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

Аппаратная зависимость и переносимость ОС

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

Типовые средства аппаратной поддержки ОС

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

•  средства поддержки привилегированного режима;

•  средства трансляции адресов;

•  средства переключения процессов;

•  система прерываний;

•  системный таймер;

• средства защиты областей памяти.

52. Операційні системи реального часу (ОСРЧ)

Операційна система реального часу, ОСРЧ (англ. Real-Time Operating System) — один із типів операційної системи. Є багато визначеннь терміну, які іноді суперечать одне одному

Найбільш розповсюдженими визначеннями операційної системи реального часу є:

• ОС, в якої успішність роботи будь-якої програми залежить не тільки від її логічної правильності, але і від часу, за який вона отримала цей результат. Якщо система не може задовольнити часовим обмеженням, повинен бути зафіксований збій в її роботі^[1]

• Стандарт POSIX 1003.1 дає визначення «Реальний час в операційних системах — це здатність операційної системи забезпечити рівень сервісу, який вимагається за визначений проміжок часу»

• ОС, яка реагує за передбачуваний час на непередбачувану появу зовнішніх подій

• Інтерактивні системи постійної готовності. До категорії ОСРЧ їх відносять виходячи з маркетингових міркувань і якщо інтерактивну програму називають «працюючою в реальному часі», то це означає лиш те, що запити від користувача обробляються із затримкою, непомітною для людини.

• Іноді поняття системи реального часу ототожнюють зі «швидкою системою», але це не завжди правильно, оскільки важливий не час затримки реакції ОСРЧ, а те, щоб цього часу було достатньо для прикладної програми, яка розглядається і щоб його було гарантовано.

• В багатьох спеціалізованих сферах вводять свої поняття «реального часу». Наприклад, процес цифрової обробки сигналу називають таким, що відбувається в реальному часі, якщо аналіз та/або генерація даних можуть бути проведені в той же час, що і аналіз/генерація тих самих даних без цифрової обробки сигналу. Наприклад, якщо при обробці аудіо даних необхідно 2.01 секунд на аналіз 2.00 секунд звуку, то це не процес реального часу. Якщо потрібно 1.99 секунд, то це процес реального часу.

Іноді розрізняють системи «жорсткого» та «м'якого» реального часу. ОС «жорсткого» реального часу гарантує виконання деяких дій в заданий інтервал часу, ОС «м'якого» реального часу, як правило, встигають виконати дії за заданий проміжок часу, але повністю не гарантують це. Більшість програмного забезпечення орієнтовано на «м'який» реальний час.

Для подібних систем характерно:

• гарантований час реакції на зовнішні події (переривання від обладнання);

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

• підвищення вимог до часу реакції на зовнішні події чи реактивності (затримка виклику обробника переривання не більш ніж десяток мілісекунд, затримка при перемиканні задач не більш ніж сотні мілісекунд)

Класичним прикладом задачі, де необхідна ОСРЧ є керування роботом, який бере деталь зі стрічки конвеєра. Деталь рухається і робот має лише маленький проміжок часу, коли він може її взяти. Якщо він запізниться, то деталь не буде вже на потрібній ділянці конвеєра, а отже, робота не буде виконана, незважаючи на те, що робот знаходиться в правильному положенні. Якщо він позиціонується раніше, то деталь ще не встигне під'їхати і він заблокує її шлях.