Какая часть операционной системы отвечает за выбор процессора между процессами
Планирование процессов – это деятельность диспетчера процессов, которая обрабатывает удаление запущенного процесса из ЦП и выбор другого процесса на основе конкретной стратегии.
Планирование процессов является неотъемлемой частью многопрограммных операционных систем. Такие операционные системы позволяют загружать в исполняемую память более одного процесса за один раз, и загруженный процесс совместно использует ЦП, используя временное мультиплексирование.
Алгоритмы планирования процессов в ОС
Задача планирования процессов состоит из трех действий:
- Определение момента времени для смены, выполняемого в данный момент, процесса.
- Выбор того процесса из очереди готовности, которому будет передано управление.
- Переключение контекста (переключение между процессами).
Первые два действия выполняются на программном уровне (специально написанный код) и относятся к планированию, третье – на аппаратном уровне и относится к диспетчеризации.
Информационные структуры описывающие процессы
Существует две информационные структуры по-разному описывающие процессы - контекст процесса и дескриптор процесса.
Контекст процесса
Контекст процесса содержит информацию о внутреннем состоянии процесса, а также отражает состояние аппаратуры в момент прерывания процесса и включает параметры операционной среды. Содержит часть информации необходимой для возобновления выполнения процесса с прерванного места.
В состав контекста процесса входит:
- содержимое регистров процессора (включает счётчик команд, т.е. на каком этапе находится процесс);
- размещение кодового сегмента;
- информацию об открытых данным процессом файлах;
- информацию о работах с внешними устройствами (+ коды ошибок выполненных процессором, системных вызовов, незавершенных операциях ввода-вывода).
Дескриптор процесса
Дескриптор процесса – это информационная структура, которая описывает внешнюю структуру (информацию) процессе (нужна планировщику для выполнения процесса, а так же нужна ядру в течение всего жизненного цикла процесса)
В состав дескриптора входят:
- Идентификатор процесса;
- Состояние процесса.
- Информация о привилегированности процесса.
- Информация о расположении кодового сегмента.
Дескрипторы присутствуют в качестве элементов списка. Для того, чтобы ОС выбирала процессы надо иметь идентификаторы процессов и т.д., т.е. дескрипторы. Дескрипторы отдельных процессов объединены в список, образующих таблицу процессов. Память для таблицы процессов отводиться динамически в области ядра. На основании соседних в таблице процессов ОС осуществляет планирование и синхронизацию процессов. Потоки образуют очереди готовых и ожидающих потоков путём объединения в списки дескрипторов отдельных потоков. Такая организация очередей позволяет легко их переупорядочить, включать и исключать процессы, переводить процессы из одного состояния в другое.
Создание процесса
Простейшей ОС не требуется создание новых процессов, так как внутри них работает всего одна программа, запускаемая во время включения устройства. В более сложных системах надо создавать новые процессы. Обычно они создаются:
- При запуске ОС;
- При появлении запроса на создание процесса.
Алгоритмы планирования процессов
В зависимости от того, какие критерии накладываются, алгоритмы планирования могут основываться на:
Алгоритмы, основанные на квантовании времени
Алгоритмы, основанные на квантовании времени – любому процессу на выполнение отводится определенный квант времени (несколько милисекунд). Переключение активного процесса происходит если:
- Истек срок времени, выделенного на выполнение процесса.
- Процесс завершился.
- Процесс перешел в состояние ожидания.
По истечении выделенного времени планировщик ставит другой процесс. Если до истечения времени процесс находится в режиме ожидания, запускается другой процесс. Кванты времени выделенные процессами, могут быть для разных процессов одинаковыми или различными. Кванты, выделяемые одному процессу могут быть фиксированной величины, а могут и изменяться в разные периоды жизни процесса. Некоторые из процессов используют полученные кванты времени не полностью из-за необходимости выполнить операции ввода-вывода. Тогда возникает ситуация, когда процессы с интенсивными обращениями к вводу-выводу используют только небольшую часть выделенного им процессорного времени. В качестве компенсации за не полностью использованные кванты, процессы получают привилегии при последующем обслуживании (создают две очереди готовых процессов, прежде всего просматривается вторая очередь; если она пуста, квант выделяется процессу из первой очереди)
Выбор новых процессов может быть построен по принципам:
Алгоритмы, основанные на приоритетах
Приоритет – число, характеризующее степень привилегированности процесса (обычно выражается числом). В каждой ОС это число трактуется по своему, оно может быть фиксированным или изменяться. В случае если изменяется, то называется динамическим (начальное значение устанавливает администратор) в отличие от неизменяемых, фиксированных приоритетов. Чем выше приоритет, тем выше привелегия, тем меньше времени проводит поток в очереди.
Существует 2 разновидности таких алгоритмов:
- Использующие относительные приоритеты.
- Использующие абсолютные приоритеты.
Алгоритмы планирования с относительными приоритетами – активный процесс выполняется пока не завершится или не перейдет в состояние ожидания.
Алгоритмы планирования с абсолютными приоритетами – смена процесса происходит в тот момент, когда в системе появляется процесс, приоритет которого выше приоритета выполняемого процесса.
Реально используются смешанные схемы планирования.
Вытесняющий и невытесняющий алгоритмы планирования
Существует два основных типа процедур планирования процессов - вытесняющие (preemptive) и невытесняющие (non-preemptive).
Non-preemptive multitasking - невытесняющая многозадачность - это способ планирования процессов, при котором активный процесс выполняется до тех пор, пока он сам, по собственной инициативе, не отдаст управление планировщику операционной системы для того, чтобы тот выбрал из очереди другой, готовый к выполнению процесс.
Preemptive multitasking - вытесняющая многозадачность - это такой способ, при котором решение о переключении процессора с выполнения одного процесса на выполнение другого процесса принимается планировщиком операционной системы, а не самой активной задачей.
Понятия preemptive и non-preemptive иногда отождествляются с понятиями приоритетных и бесприоритетных дисциплин, что совершенно неверно, а также с понятиями абсолютных и относительных приоритетов, что неверно отчасти. Вытесняющая и невытесняющая многозадачность - это более широкие понятия, чем типы приоритетности. Приоритеты задач могут как использоваться, так и не использоваться и при вытесняющих, и при невытесняющих способах планирования. Так в случае использования приоритетов дисциплина относительных приоритетов может быть отнесена к классу систем с невытесняющей многозадачностью, а дисциплина абсолютных приоритетов - к классу систем с вытесняющей многозадачностью. А бесприоритетная дисциплина планирования, основанная на выделении равных квантов времени для всех задач, относится к вытесняющим алгоритмам.
Основным различием между preemptive и non-preemptive вариантами многозадачности является степень централизации механизма планирования задач. При вытесняющей многозадачности механизм планирования задач целиком сосредоточен в операционной системе, и программист пишет свое приложение, не заботясь о том, что оно будет выполняться параллельно с другими задачами. При этом операционная система выполняет следующие функции: определяет момент снятия с выполнения активной задачи, запоминает ее контекст, выбирает из очереди готовых задач следующую и запускает ее на выполнение, загружая ее контекст.
При невытесняющей многозадачности механизм планирования распределен между системой и прикладными программами. Прикладная программа, получив управление от операционной системы, сама определяет момент завершения своей очередной итерации и передает управление ОС с помощью какого-либо системного вызова, а ОС формирует очереди задач и выбирает в соответствии с некоторым алгоритмом (например, с учетом приоритетов) следующую задачу на выполнение. Такой механизм создает проблемы, как для пользователей, так и для разработчиков.
Для пользователей это означает, что управление системой теряется на произвольный период времени, который определяется приложением (а не пользователем). Если приложение тратит слишком много времени на выполнение какой-либо работы, например, на форматирование диска, пользователь не может переключиться с этой задачи на другую задачу, например, на текстовый редактор, в то время как форматирование продолжалось бы в фоновом режиме. Эта ситуация нежелательна, так как пользователи обычно не хотят долго ждать, когда машина завершит свою задачу.
Поэтому разработчики приложений для non-preemptive операционной среды, возлагая на себя функции планировщика, должны создавать приложения так, чтобы они выполняли свои задачи небольшими частями. Например, программа форматирования может отформатировать одну дорожку дискеты и вернуть управление системе. После выполнения других задач система возвратит управление программе форматирования, чтобы та отформатировала следующую дорожку. Подобный метод разделения времени между задачами работает, но он существенно затрудняет разработку программ и предъявляет повышенные требования к квалификации программиста. Программист должен обеспечить "дружественное" отношение своей программы к другим выполняемым одновременно с ней программам, достаточно часто отдавая им управление. Крайним проявлением "недружественности" приложения является его зависание, которое приводит к общему краху системы. В системах с вытесняющей многозадачностью такие ситуации, как правило, исключены, так как центральный планирующий механизм снимет зависшую задачу с выполнения.
Однако распределение функций планировщика между системой и приложениями не всегда является недостатком, а при определенных условиях может быть и преимуществом, потому что дает возможность разработчику приложений самому проектировать алгоритм планирования, наиболее подходящий для данного фиксированного набора задач. Так как разработчик сам определяет в программе момент времени отдачи управления, то при этом исключаются нерациональные прерывания программ в "неудобные" для них моменты времени. Кроме того, легко разрешаются проблемы совместного использования данных: задача во время каждой итерации использует их монопольно и уверена, что на протяжении этого периода никто другой не изменит эти данные. Существенным преимуществом non-preemptive систем является более высокая скорость переключения с задачи на задачу.
Однако почти во всех современных операционных системах, ориентированных на высокопроизводительное выполнение приложений (UNIX, Windows NT, OS/2), реализована вытесняющая многозадачность. Вытесняющую многозадачность часто называют истинной многозадачностью.
Состояния процесса в ОС
Долгосрочный планировщик
Это также называется планировщиком заданий . Долгосрочный планировщик определяет, какие программы допущены в систему для обработки. Он выбирает процессы из очереди и загружает их в память для выполнения. Процесс загружается в память для планирования ЦП.
Основной целью планировщика заданий является обеспечение сбалансированного сочетания заданий, таких как привязка ввода-вывода и привязка процессора. Он также контролирует степень мультипрограммирования. Если степень мультипрограммирования стабильна, то средняя скорость создания процесса должна быть равна средней скорости вылета процессов, покидающих систему.
В некоторых системах долгосрочный планировщик может быть недоступен или минимален. Операционные системы с разделением времени не имеют долгосрочного планировщика. Когда процесс меняет состояние с нового на готовое, тогда используется долгосрочный планировщик.
Планировщики
Планировщики – это специальное системное программное обеспечение, которое обрабатывает планирование процессов различными способами. Их основная задача – выбрать задания для отправки в систему и решить, какой процесс запустить. Планировщики бывают трех типов –
- Долгосрочный планировщик
- Краткосрочный планировщик
- Среднесрочный планировщик
Создание процесса
Создание процесса:
- ОС создает контекст и дескриптор процесса.
- Загрузка кодового сегмента в оперативную память.
- Дескриптор помещается в очередь процессов, находящихся в готовности.
С этого момента можно считать, что процесс стартовал.
Разберём подробно вопрос создания процесса. Когда запускается приложение, Операционная Система создаёт две информационные структуры: контекст и дескриптор (идентификатор и т.д.). Кодовый элемент грузится в оперативную память (информацию о нём заносится в контекст). Затем дескриптор процесса включается в очередь процессов; далее планировщик решает, что процесс должен быть выполнен, а дескриптор процесса находится в очереди готовых процессов. Прежде прервать выполнение процесса, ОС вначале сохраняет его контекст, чтобы в последствие использовать эту инструкцию для последовательного возобновления. Затем контекст обновляется (переключение контекста) и активный контекст получает информацию о новом процессе. Далее процессу выделяются ресурсы, процессорное время и т.д. При удалении процесса: уничтожается дескриптор и удаляется контекст. Новый процесс может получить дескриптор с тем же номером.
Планирование процессов
Планирование необходимо для организации более производительной работы многозадачной, многопользовательской ОС. В однозадачный однопользовательских ОС, система не ведет никакого планирования запуска на выполнения отдельных процессов. Все задачи планирования выполняет пользователь, работающий за однозадачной однопользовательской ОС. Однако для многозадачных многопользовательских ОС (UNIX) есть необходимость в таком планировании, так как в очереди на выполнение обычно стоит большое количество различных процессов. Планирование проявляется так же в выделении различных приоритетов, объема ОП, количество выделяемых ресурсов и процессорного времени, предоставляемого отдельным процессам.
Для всех ОС соблюдается следующие принципы планирования:
- Предоставление каждому процессу справедливого (одинакового) количество процессорного времени.
- Производится принудительное выполнение политики приоритетов выполняющихся процессов.
- Планирование производится таким образом чтобы поддерживался максимальный баланс занятости системы. Например: в очереди на выполнение имеются 4 процесса, 2 из которых требуют значительного количество работы устройств ввода вывода и малого количество процессорного времени, а 2 других процесса требуют большого количество процессорного времени и малого времени работы устройств ввода вывода. Все процессы будут выполнятся значительно скорее если они будут запускаться попарно: процесс требующий большого количество работы устройств ввода вывода и малого количество времени процессора, а так же процесс требующий большого количество процессорного времени и малого времени работы устройств ввода вывода.
Для ОС пакетной обработки данных кроме того используются следующие критерии планирования:
- Максимальная пропускная способность ЭВМ в целом.
- Максимальное использование процессора.
- Минимальное время выполнения одного задания (процесса).
Для интерактивных ОС при планировании ведется учет того, что ОС должна обладать минимальным временем отклика на запрос пользователя. Кроме того в этом случи ОС должна уметь настраиваться под пожелания отдельных пользователей.
Для ОС реального времени при планировании должно обеспечиваться окончание работы процесса к заданному времени для предотвращения потери данных, исключения возможных взаимоблокировок процессов, предсказуемости поведения ОС.
Проблема синхронизации процессов
Рассмотрим пример: в системе два прикладных процесса, которые будут работать с очередью печати.
Какие особенности характерны для современных универсальных операционных систем?
+ 1. поддержка многозадачности
+ 2. поддержка сетевых функций
+ 3. обеспечение безопасности и защиты данных
4. предоставление большого набора системных функций разработчикам приложений
Какие утверждения относительно понятия «API-функция» являются правильными?
+ 1. API-функции определяют прикладной программный интерфейс
+ 2. API-функции используются при разработке приложений для доступа к ресурсам компьютера
3. API-функции реализуют самый нижний уровень ядра системы
4. API-функции — это набор аппаратно реализованных функций системы
Какие особенности характерны для ОС Unix
+ 1. открытость и доступность исходного кода
2. ориентация на использование оконного графического интерфейса
+ 3. использование языка высокого уровня С
+ 4. возможность достаточно легкого перехода на другие аппаратные платформы
Какие типы операционных систем используются наиболее часто в настоящее время?
+ 1. системы семейства Windows
+ 2. системы семейства Unix/Linux
3. системы семейства MS DOS
4. системы семейства IBM OS 360/370
Какие задачи необходимо решать при создании мультипрограммны х ОС
+ 1. защита кода и данных разных приложений, размещенных вместе в основной памяти
+ 2. централизованное управление ресурсами со стороны ОС
+ 3. переключение процессора с одного приложения на другое
4. необходимость размещения в основной памяти кода и данных сразу многих приложений
Какое соотношение между используемыми на СЕРВЕРАХ операционными системами сложилось в настоящее время?
+ 1. примерно поровну используются системы семейств Windows и Unix/Linux
2. около 10 % — системы семейства Windows, около 90 % — системы смейства Unix/Linux
3. около 90 % — системы семейства Windows, около 10 % — системы семейства Unix/Linux
4. около 30 % — системы семейства Windows, около 30 % — системы семейства Unix/Linux, около 40 % — другие системы
Какие утверждения относительно понятия «Ядро операционной системы» являются правильными?
+ 1. ядро реализует наиболее важные функции ОС
+ 2. подпрограммы ядра выполняются в привилегированно м режиме работы процессора
3. ядро в сложных ОС может строиться по многоуровневому принципу
4. ядро всегда реализуется на аппаратном уровне
Какие шаги в алгоритме взаимодействия приложения с системой выполняются операционной системой
1. небольшую структуру данных, содержащую информацию о некотором событии
2. специальную API-функцию, вызываемую системой при возникновении события
3. однобайтовое поле с кодом происшедшего события
+ 4. небольшое окно, выводящее пользователю информацию о возникшем событии
Какие утверждения относительно иерархии окон являются справедливыми
+ 1. главное окно может содержать любое число подчиненных окон
+ 2. любое подчиненное окно может содержать свои подчиненные окна
3. подчиненные окна могут быть двух типов – дочерние и всплывающие
+ 4. приложение может иметь несколько главных окон
Как можно узнать координаты текущего положения мыши при нажатии левой кнопки
+ 1. с помощью события WM_LbuttonDown и его поля LPARAM
2. с помощью события WM_LbuttonDown и его поля WPARAM
3. с помощью события WM_LbuttonDown и его полей WPARAM и LPARAM
4. с помощью события WM_LbuttonCoordi nates
Какие функции можно использовать для получения контекста устройства?
Какая инструкция (оператор) является основной при написании оконной функции?
+ 1. инструкция множественного выбора типа Case — Of
2. условная инструкция if – then
3. инструкция цикла с известным числом повторений
4. инструкция цикла с неизвестным числом повторений
Какой вызов позволяет добавить строку в элемент-список?
+ 1. SendMessage (MyEdit, lb_AddString, 0, строка)
2. SendMessage (“Edit”, lb_AddString, 0, строка)
3. SendMessage (MyEdit, AddString, 0, строка)
4. SendMessage (MyEdit, строка, lb_AddString, 0)
Какие утверждения относительно оконной функции являются правильными
+ 1. оконная функция принимает 4 входных параметра
+ 2. тело оконной функции – это инструкция выбора с обработчиками событий
+ 4. оконная функция явно вызывается из основной функции приложения
Что может быть причиной появления внутреннего прерывания
+ 1. попытка деления на ноль
2. попытка выполнения запрещенной команды
+ 3. попытка обращения по несуществующему адресу
4. щелчок кнопкой мыши
Какие операции определяют взаимодействие драйвера с контроллером
+ 1. проверка состояния устройства
+ 2. запись данных в регистры контроллера
+ 3. чтение данных из регистров контроллера
4. обработка прерываний от устройства
Какие операции включает в себя вызов обработчика нового прерывания
+ 1. обращение к таблице векторов прерываний для определения адреса первой команды вызываемого обработчика
2. сохранение контекста для прерываемого программного кода
+ 3. занесение в счетчик команд начального адреса вызываемого обработчика
+ 4. внесение необходимых изменений в таблицу векторов прерываний
Что входит в программный уровень подсистемы ввода/вывода
2. диспетчер ввода/вывода
+ 3. системные вызовы
Что определяет понятие “порт ввода/вывода”
+ 1. порядковый номер или адрес регистра контроллера
2. машинную команду ввода/вывода
3. устройство ввода/вывода
4. контроллер устройства ввода/вывода
Какие существуют типы прерываний
+ 1. внешние или аппаратные прерывания
+ 2. внутренние прерывания или исключения
+ 3. программные псевдопрерывания
4. системные прерывания
Какие утверждения относительно понятия прерывания являются правильными
+ 1. прерывания — это механизм реагирования вычислительной системы на происходящие в ней события
2. прерывания используются для синхронизации работы основных устройств вычислительной системы
+ 3. прерывания возникают в непредсказуемые моменты времени
4. прерывания — это основной механизм планирования потоков
Какую информацию могут содержать регистры контроллеров устройства
+ 1. текущее состояние устройства
+ 2. текущую выполняемую устройством команду
3. данные, передаваемые от устройства системе
4. данные, передаваемые системой устройству
Как выстраиваются аппаратные прерывания в зависимости от их приоритета
1. сбой аппаратуры > таймер > дисковые устройства > сетевые устройства > клавиатура и мышь
2. сбой аппаратуры > таймер > дисковые устройства > клавиатура и мышь > сетевые устройства
+ 3. таймер > сбой аппаратуры > дисковые устройства > сетевые устройства > клавиатура и мышь
4. сбой аппаратуры > дисковые устройства > таймер > сетевые устройства > клавиатура и мышь
Переключение контекста
Переключение контекста – это механизм для сохранения и восстановления состояния или контекста ЦП в блоке управления процессом, так что выполнение процесса может быть возобновлено с той же точки в более позднее время. Используя эту технику, переключатель контекста позволяет нескольким процессам совместно использовать один ЦП. Переключение контекста является неотъемлемой частью функций многозадачной операционной системы.
Когда планировщик переключает ЦП с выполнения одного процесса на выполнение другого, состояние текущего запущенного процесса сохраняется в блоке управления процессом. После этого состояние следующего процесса загружается с его собственной печатной платы и используется для настройки ПК, регистров и т. Д. В этот момент может начаться выполнение второго процесса.
Переключение контекста требует значительных вычислительных ресурсов, поскольку регистр и состояние памяти должны быть сохранены и восстановлены. Чтобы избежать количества времени переключения контекста, некоторые аппаратные системы используют два или более набора регистров процессора. Когда процесс переключается, следующая информация сохраняется для последующего использования.
Мне бы хотелось рассказать немного о многозадачности операционной системы. О концепте управления процессами и потоками с точки зрения ОС (и процессора/процессоров) как системы массового обслуживания. О том, «как это происходит».
Процессов ведь много, а ресурсы ограничены. На всех сразу не хватает. Что же делать? И вот тут возникает аналогия с системой массового обслуживания. Можно представить пул процессов как очередь в кассу. Ой, простите, в процессор. И архаичных вариантов обработки такой очереди [мне известно] три.
Предислование
Изначально я буду ориентироваться на то, что процессор один. Для упрощения. Потом расскажу, в чем, на мой, взгляд разница.
Для начала: общие сведения.
Картинка процессора
Что же такое «процесс» и в чем его отличие от «потока»? Процесс — это (грубо говоря) — заявка на реализацию чего-либо. Точнее, на потребление системных ресурсов. ОС генерирует системную информацию, в которой говорит, какие необходимы это процессу ресурсы. А так же о тех ресурсах, которые ему фактически были выделены. И это — для каждого вновь создаваемого процесса отдельно. О том, сколько ему необходимо памяти, сколько процессорного времени, и т.д.
Так о чем же я? Ах, да.
О способах обработки очереди процессов
Архаичных способов обработки очереди, как я говорила, мне известно три.
Т.е., каждому процессу выделяется определенный квант времени, после которого процессор радостно рапортует: «Свободная касса!», и получает на обслуживание следующий процесс. Текущий процесс же идет в конец очереди. Ибо «все равны». Недостатки: (грубый пример) у Вас идет видеоконференция. Очень важная. Прямо на самом интересном месте: бабах! И начинает печатается «важный» документ. Он же письмо с просьбой перенести время доставки ежедневного обеда с 13:00 на 14:00. А Ваша видеоконференция «неизвестно когда» будет возобновлена. Конечно, на практике так не бывает, потому что принтер работает по прерыванию, и там вообще все иначе. Но аналогия, мне кажется, в целом ясна.
Это когда «не все равны». Процессу назначается приоритет, и пока процесс с более высоким приоритетом не будет обслужен (ой, простите, обработан), другие к кассе (ой, простите, к процессору) подойти не смогут. Недостатки: могут быть процессы, которые из-за низкого приоритета не обработаются вообще никогда. Т.е., письмо Вы так никогда и не распечатаете.
На практике же зачастую используется подход «все равны, но некоторые ровнее». Т.е., «смешанный». Когда процессу выделяется квант времени и приоритет одновременно. Тогда процесс уходит не в конец очереди, а куда-то в «свою» середину. И там ждет.
Схема ясна, но как же обрабатываются процессы? В какой очередности? Тут все та же система массового обслуживания. Есть несколько подходов к обработке процессов в случае квантования и «смешанного» типа:
— FIFO. Первый пришел, первый вышел. (First-In-First-Out)
— LIFO. Последний пришел, первый вышел. (ИМХО, не очень честно… ) (Last-In-First-Out)
— SIRO. Ну, тут полный рандом. Service-In-Random-Out.
В случае «чистых» приоритетов таких вопросов не возникает, ясное дело.
А что же там с многопроцессорными системами?
Ведь я обещала поделиться своими мыслями на этот счет. Ну, давайте представим, что касс (процессоров) несколько. И тут те же принципы, только либо несколько очередей, и процессы попадают в рандомном или не очень порядке в очередь (что мне кажется не очень логичным, ну, например, хотя бы потому, что на новых процессорах по прежнему работают «однопроцессорные» системы). Либо так же очередь (пул, из которого берутся процессы) — одна, а обрабатывают их несколько касс. Но это исключительно мысли автора, не более того.
Может возникнуть вполне резонный вопрос.
А в чем же все-таки отличие процесса от потока?
А все просто. В начале статьи вскользь упоминалось, что программе для выполнения необходимы ресурсы и процессорное время. Так вот, система «воспринимает» процесс как заявку на любые виды ресурсов, кроме процессорного времени. Заявка на процессорное время — это поток. Именно процессорное время распределяется между потоками. Таким образом, процесс состоит из нескольких потоков. Раньше, конечно, это все было единое целое. И процесс, и поток, и все в одном, и вообще, «зачем платить больше?». Как оказалось, в данном случае мы, скорее, «платим меньше». Когда потоков несколько.
Для того, чтобы процессы не могли вмешиваться в распределение ресурсов, система их «изолирует». Предоставляет каждому из них своё виртуальное адресное пространство. Так что ни один процесс не может получить прямого доступа к командам и данным другого процесса.
При необходимости взаимодействия процессы обращаются к ОС, в буквальном смысле, как к посреднику. А она уже им помогает, выдаёт средства связи.
А вот между потоками одного и того же процесса нет полной защиты. Потому что это не только невозможно, но и никому не нужно. Чтобы обмениваться данными потокам вовсе не обязательно обращаться к ОС. Они используют общую память. Один записывает данные, другой читает. И все хорошо. Кроме того, потоки разных процессов по-прежнему хорошо защищены друг от друга.
Мультипрограммирование более эффективно на уровне потоков, а не процессов. Каждый поток имеет свой счетчик команд и стек. Задача, оформленная в виде нескольких потоков может быть выполнена быстрее за счет параллельного (или псевдопараллельного в однопроцессорной системе) выполнения её частей.
Очевидные выводы
Процесс — это заявка на потребление всех ресурсов, кроме процессорного времени. Процессы изолированы друг от друга, и включает в себя потоки. Собственно, потоки — это заявки на потребление этого самого процессорного времени.
Наибольший эффект от введения многопоточной обработки достигается в мультипроцессорных системах, в которых потоки (даже в рамках одного процесса) могут выполняться действительно параллельно, а не псевдо.
Ко всему прочему, был продемонстрировано на примере непосредственно концепт работы системы [массового обслуживания] как таковой.
Я немного «смахлевала» в начале и в середине статье, рассказывая по поводу процессорного времени для «процесса» как такового. Но не сильно, и, я надеюсь, Вы меня простите за эту вынужденную неточность.
Проце́сс — это в выполняемая в данный момент программа. Выполнение процесса должно осуществляться последовательно. Процесс определяется как сущность, представляющая основную единицу работы, которая должна быть реализована в системе.
На любой ЭВМ всегда имеется процесс соответствующий операционной системе (ОС) этой ЭВМ, а также один или несколько процессов отвечающих пользовательским программам. На однопроцессорных ЭВМ в любой момент времени может выполнятся только один процесс. Любая ОС должна уметь производить запуск процессов, приостановку, их выполнение, завершение их выполнения и синхронизацию процессов между собой. Для каждого процесса ОС предоставляет собственное адресное пространство. Это адресное пространство начинается от нуля и продолжается непрерывно до предела соответствующего ЭВМ и ОС. С целью обеспечения переносимости адресное пространство всегда начинается с нуля. Ни один процесс кроме ОС не знает в какой именно части физической памяти и каким образом располагается его адресное пространство. Это прерогатива ОС, которая должна наиболее эффективным образом выполнять выполняющиеся процессы.
Операционная система контролирует следующую деятельность, связанную с процессами:
- создание и удаление процессов
- планирование процессов
- синхронизация процессов
- коммуникация процессов
- разрешение тупиковых ситуаций
Каждому процессу ОС системой выделяются ресурсы: дисковое пространство, устройство ввода вывода, канал передачи информации и прочее. Каждый процесс имеет возможность создавать другие процессы и контролировать их выполнения. Каждому процессу в ОС отводятся определенные права. Эти права максимальны для самой ОС, имеют промежуточные значения для подсистем ОС (драйвера) и минимальные права соответствуют выполняющимся пользовательским программам. ОС для каждого из процесса хранит всю информацию об этих процессах в специальных таблицах. В этих таблицах обязательно описываются права процесса, полное состояние регистров процессора для данного процесса, объем ОП отводимый процессу и отображение этой памяти на реальную физическую память, а так же список всех ресурсов, отводимых данному процессу. При переключении с одного процесса на другой ОС пользуется этими учетными записями.
Порождение нового процесса
Порождение нового процесса это длительная процедура, так как ОС должна выполнить множество действий:
- Выделить процессу необходимые ресурсы (адресное пространство, файлы, устройство и т.д.);
- Произвести инициализацию этих ресурсов (загрузить выполняемую программу в ОП, инициализировать первое начальное значение регистров и стеков, открыть файлы и т.д.);
- Занести всю необходимую информацию в специальную таблицу, описывающую процессу в системе;
- Передать управление новому процессу.
Переключение между отдельными выполняющимися процессами так же длительная процедура. В этом случи ОС должна произвести дополнительные (обычно в таблице соответствующей выполняемому процессу) от регистров соответствующих выполняемому процессу, карту отображения в памяти процесса на реальную физическую память, сохранить состояние всех файлов и устройств используемых процессом. После этого ОС должна выбрать полное описание процесса на который она переключается из таблицы (инициализировать регистры, карту отображения памяти процесса на физическую память, состояние файлов и устройств). Переключение между процессами осуществляется в том числе по прерыванию таймера. Обычно системному программисту предоставляется возможность задания максимального времени выполнения одного процесса, после которого произойдет прерывание по таймеру и переключение на другой процесс. При задании маленького значения этого времени у системы будет мало времени на отклик на возникающие события, однако при этом значительная часть процессорного времени будет тратиться на переключение между процессами. При задании большого времени таймера накладные расходы, связанные с переключениями между процессами будут уменьшаться, однако будет ухудшаться отклик системы на возникающие события. При завершении процесса происходит закрытие всех файлов, освобождение всех ресурсов, занятых всех ресурсов и вычеркивании его из таблицы процессов.
Состояние процесса в ходе жизненного цикла в ОС
В ходе жизненного цикла каждый процесс переходит из одного состояния в другое в соответствии с алгоритмом планирования процессов, реализуемым в данной операционной системе.
В состоянии ВЫПОЛНЕНИЕ в однопроцессорной системе может находиться только один процесс, а в каждом из состояний ОЖИДАНИЕ и ГОТОВНОСТЬ - несколько процессов, эти процессы образуют очереди соответственно ожидающих и готовых процессов. Жизненный цикл процесса начинается с состояния ГОТОВНОСТЬ, когда процесс готов к выполнению и ждет своей очереди. При активизации процесс переходит в состояние ВЫПОЛНЕНИЕ и находится в нем до тех пор, пока либо он сам освободит процессор, перейдя в состояние ОЖИДАНИЯ какого-нибудь события, либо будет насильно "вытеснен" из процессора, например, вследствие исчерпания отведенного данному процессу кванта процессорного времени. В последнем случае процесс возвращается в состояние ГОТОВНОСТЬ. В это же состояние процесс переходит из состояния ОЖИДАНИЕ, после того, как ожидаемое событие произойдет.
Информация о процессе:
- Режим работы процессора.
- Информация об открытых файлах.
- Регистры.
- Состояние внешних устройств.
- Операции ввода – вывода.
Взаимоблокировка процессов
Блокировкой процессов называют состояние системы, при котором 2 или более процессов не могут продолжать свое выполнение из-за отсутствия необходимых для этого ресурсов.
Взаимоблокировка возникает в многозадачных многопользовательских ОС. Чем большее количество различных задач выполняется на машине, и чем меньше ее ресурсы, тем больше вероятность возникновение взаимоблокировок. При этом ситуация напоминает подающий с горы снежный ком. Количество блокированных процессов быстро возрастает до тех пор, пока в системе не останется не одного работающего процесса. ОС практически полностью прекращает полезное функционирование а ЭВМ простаивает. Блокировки процессов возникают либо сами собой, либо инициализируются внешними атаками. Например: атаки вирусов (хакеров) на определенный сайт приводят к возникновению блокировки на обслуживающим этот сайт ЭВМ. Это вызвано перегрузкой работы соответствующей ЭВМ, когда в условии ограниченности ресурсов (хотя эти ресурсы у майнфреймов могут быть очень большими: несколько сотен дисков, десятки терабайт ОП и т.д. ) ЭВМ должна одновременно обработать очень большое количество запросов.
В итоге ЭВМ нужно будет заново перезагружать. Для майнфрейма каждая перезагрузка аналогична потере нескольких миллионов долларов, такова цена за невыполненные вовремя различные запросы. Имеются различные способы выхода из блокировок:
- Снятие оператором выполняющихся процессов до тех пор, пока не исчезнет взаимоблокировка. Этот путь эффективен лишь в том случае, когда количество выполняющихся процессов не очень велико (не превышает 100). При большом количестве выполняющихся процессов этот путь чаще всего не помогает преодолеть блокировку.
- Перезагрузка системы этот путь преодоления блокировок наиболее радикальный, но и наиболее дорогой.
- Рестарт системы с так называемой контрольной точки.
Контрольная точка - это полное состояние ЭВМ запомненное на внешнем носители. Для больших ЭВМ организация контрольной точки требует больших ресурсов и времени, поскольку на внешний носитель нужно будет запомнить полное состояние всех регистров ЭВМ, всей ее ОП (несколько десятков терабайт на майнфреймах), а так же полное состояние регистров и ОП каждого из устройств ЭВМ (несколько десятков тысяч устройств на майнфреймах). Несмотря на то что организация контрольной точки требует большого количества времени и ресурсов, ее регулярно проводят с различной периодичностью (раз в час) для того чтобы уменьшить неизбежные финансовые потери от рестарта ЭВМ.
Имеются два противоположных способа борьбы с взаимоблокировками:
- Полное игнорирование угроз возникновения взаимоблокировок.
- Построение такой ОС, которая просчитывает на несколько шагов вперед ситуацию, которая может возникнуть в ЭВМ после запуска определенного процесса. Такое построение ОС ведет к существенному усложнению ее структуры, однако не решает проблемы на 100%, так как любая сложная программа имеет большое количество не выявленных ошибок.
На построение ОС безопасных по отношению к взаимоблокировкам идут лишь в некоторых случаях, в которых возникновение блокировок может привести к катастрофическим последствиям. Например: на ЭВМ управляющих системами стратегических ракет и противоракетной обороны.
Игнорирование угрозы взаимоблокировок приводит к тому, что ОС плохо контролирует последовательность выделения ресурсов отдельным процессам, поэтому с течением времени неизбежно возникновение блокировки. Почти все ОС построены по такому принципу. На майнфреймах, при проектировании, такая структура ОС была принята , что при среднем количестве запросов на ЭВМ и большом объеме ее ресурсов возникновение блокировок было маловероятным. Затраты на написание сложной безопасной ОС представлялись проектировщиками гораздо больше чем экономические потери возникающие из-за редких возникновении взаимоблокировок. Однако с появлением вирусов и хакерских атак вероятность перегрузки ЭВМ и возникновение блокировок очень сильно возросла.
Процесс (задача) – абстракция, описывающая выполняющуюся в рамках ОС программу. Для ОС процесс – единица работы, которая потребляет системные ресурсы.
Задачи, решаемые подсистемой управления процессами:
- Планирование процессов - распределение процессорного времени: что, сколько, и когда выполняется;
- Создание и уничтожение процессов - ОС обеспечивает старты, выделяет ресурсы, обеспечивает уничтожение, освобождение ресурсов и т.д.
- Обеспечение процессов системными ресурсами (памятью, различными устройствами)
- Поддержка взаимодействия между процессами (обеспечение межпроцессорного взаимодействия)
С понятием управления процессами в ОС связаны следующие технологии:
Модель двух состояний
Модель процесса с двумя состояниями относится к рабочим и неработающим состояниям, которые описаны ниже –
Когда создается новый процесс, он входит в систему как в рабочем состоянии.
Процессы, которые не запущены, остаются в очереди, ожидая своей очереди на выполнение. Каждая запись в очереди является указателем на определенный процесс. Очередь реализуется с помощью связанного списка. Использование диспетчера заключается в следующем. Когда процесс прерывается, этот процесс передается в очередь ожидания. Если процесс завершен или прерван, процесс отбрасывается. В любом случае диспетчер затем выбирает процесс из очереди для выполнения.
Когда создается новый процесс, он входит в систему как в рабочем состоянии.
Процессы, которые не запущены, остаются в очереди, ожидая своей очереди на выполнение. Каждая запись в очереди является указателем на определенный процесс. Очередь реализуется с помощью связанного списка. Использование диспетчера заключается в следующем. Когда процесс прерывается, этот процесс передается в очередь ожидания. Если процесс завершен или прерван, процесс отбрасывается. В любом случае диспетчер затем выбирает процесс из очереди для выполнения.
Краткосрочный планировщик
Он также называется планировщиком ЦП . Его основная цель – повысить производительность системы в соответствии с выбранным набором критериев. Это изменение состояния готовности в рабочее состояние процесса. Планировщик ЦП выбирает процесс среди процессов, готовых к выполнению, и выделяет ЦП одному из них.
Краткосрочные планировщики, также известные как диспетчеры, принимают решение о том, какой процесс выполнять дальше. Краткосрочные планировщики быстрее, чем долгосрочные.
Среднесрочный планировщик
Среднесрочное планирование является частью обмена . Удаляет процессы из памяти. Это уменьшает степень мультипрограммирования. Среднесрочный планировщик отвечает за обработку замененных процессов.
Работающий процесс может быть приостановлен, если он сделает запрос ввода-вывода. Приостановленные процессы не могут достичь прогресса. В этом случае, чтобы удалить процесс из памяти и освободить место для других процессов, приостановленный процесс перемещается во вторичное хранилище. Этот процесс называется обменом , а процесс называется обмен или выкатывание. Обмен может быть необходимым для улучшения технологического процесса.
Сравнение среди Планировщика
SN | Долгосрочный планировщик | Краткосрочный планировщик | Среднесрочный планировщик |
---|---|---|---|
1 | Это планировщик работы | Это планировщик процессора | Это планировщик обмена процессами. |
2 | Скорость меньше, чем краткосрочный планировщик | Скорость самая быстрая среди двух других | Скорость находится между краткосрочным и долгосрочным планировщиком. |
3 | Контролирует степень мультипрограммирования | Это обеспечивает меньший контроль над степенью мультипрограммирования | Это уменьшает степень мультипрограммирования. |
4 | Она практически отсутствует или минимальна по времени | Это также минимальная система разделения времени | Это часть систем разделения времени. |
5 | Он выбирает процессы из пула и загружает их в память для выполнения | Он выбирает те процессы, которые готовы выполнить | Это может повторно ввести процесс в память, и выполнение может быть продолжено. |
Синхронизация процессов в ОС
Содержание
Состояния процесса
Процесс, помимо главного рабочего состояния, может находиться в других состояниях.
Linux Процесс в ОС Linux может находиться в одном из следующих состояний:
R (running) — процесс исполняется или ожидает своей очереди;
D — непрерываемый сон (ожидает события);
S — прерываемый сон (ожидает определённого события или сигнала);
T — остановка — процесс приостановлен чем-либо;
Z (zombie) — процесс уже завершился, но ещё не передал родительскому процессу свой код возврата.
Очереди планирования процессов
ОС поддерживает все печатные платы в очередях планирования процессов. ОС поддерживает отдельную очередь для каждого из состояний процессов, а печатные платы всех процессов в одном и том же состоянии выполнения помещаются в одну и ту же очередь. Когда состояние процесса изменяется, его печатная плата отсоединяется от текущей очереди и перемещается в новую очередь состояний.
Операционная система поддерживает следующие важные очереди планирования процессов:
Очередь заданий – в этой очереди хранятся все процессы в системе.
Готовая очередь – эта очередь хранит набор всех процессов, находящихся в основной памяти, готовых и ожидающих выполнения. Новый процесс всегда помещается в эту очередь.
Очереди устройства – процессы, которые заблокированы из-за недоступности устройства ввода-вывода, составляют эту очередь.
Очередь заданий – в этой очереди хранятся все процессы в системе.
Готовая очередь – эта очередь хранит набор всех процессов, находящихся в основной памяти, готовых и ожидающих выполнения. Новый процесс всегда помещается в эту очередь.
Очереди устройства – процессы, которые заблокированы из-за недоступности устройства ввода-вывода, составляют эту очередь.
ОС может использовать разные политики для управления каждой очередью (FIFO, Round Robin, Priority и т. Д.). Планировщик ОС определяет, как перемещать процессы между готовыми и запущенными очередями, которые могут иметь только одну запись на процессорное ядро в системе; на приведенной выше диаграмме он был объединен с процессором.
Инициализация
При старте процесса производится выделение ему ряда файлов. Как правило эти файлы наследуются от того процесса который стартует в процессе. Вновь созданный процесс в свою очередь может создавать, модифицировать и закрывать принадлежащие ему файлы.
В UNIX системах устанавливаются строгая иерархия процессов по принципу родитель потомок. Родитель имеет право контролировать работу потомка, приостанавливать или завершать его выполнение. Потомок не имеет никаких прав по отношению к родителям, «братьям», «дядям».
В Windows системах нет жесткой иерархии. Все процессы - равноправны. Ни один процесс (кроме ядра ОС) не имеет право контролировать работу другого процесса. Так же, в силу реализации Windows, один и тот же процесс может оказываться на различных уровнях прав.
В процессе выполнения процесса могут возникать сигналы тревоги. Они связаны с различными внештатными ситуациями: с попыткой деления на ноль, выходом за пределы доступного адресного пространства, неисправностью использованных устройств. При возникновении такого сигнала, управление передается ОС, которая должна предпринять необходимые корректирующие действия. В развитых ОС возможна регистрация процессом собственного обработчика сигнала тревоги. Обычно этот обработчик пишется в виде подпрограммы в программе соответствующей процессу. В этом случи при возникновении сигнала тревоги управление передается этому обработчику.
Содержание
Читайте также: