Метод состоит в размещении пакета потоков целиком в пространстве пользователя.

Создание процесса.

Основные события, приводящие к созданию процесса:

· ○ Инициализация системы

· ○ Выполнение изданного работающим процессом системного запроса на создание процесса

· ○ Запрос пользователя на создание нового процесса

· ○ Инициирование пакетного задания

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

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

В UNIX существует только один системный запрос, направленный на создание процесса: fork.
Этот запрос создает дубликат вызываемого процесса. После выполнения запроса fork двум процессам - родительскому и дочернему - соответствуют одинаковые образы памяти, строки окружения и открытые файлы. Обычно, дочерний процесс выполняет системный вызов execveдля изменения образа памяти и запуска новой программы.

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

Завершение процесса

Основные события, приводящие к завершению процесса:

· ○ Обычный выход (преднамеренно)

· ○ Выход по ошибке (преднамеренно)

· ○ Выход по неисправимой ошибке (непреднамеренно)

· ○ Уничтожение другим процессом (непреднамеренно)

В основном, процессы завершаются по мере выполнения своей работы. После окончания компиляции программы, компилятор выполняет системный запрос, чтобы сообщить операционной системе о завершении работы.
В UNIX этот запрос - exit,
а в Windows -ExitProcess.

Так же, причиной завершения процесса может служить выполнение другим процессом системного запроса на уничтожение процесса. В UNIX такой системный запрос - kill, а в Windows - TerminateProcess. В обоих случаях “киллер” должен обладать соответствующими правами к убиваемому процессу.

2)Поток, Использование потоков.

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

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

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

· На рис. б) представлен один процесс с тремя потоками управления.

В обоих случаях мы имеем три потока, но на рис. а) каждый из них имеет собственное адресное пространство, а на рис. б) потоки разделяют единое адресное пространство.

-------------
#Элементы совместно используемые всеми потоками процесса(элементы процесса)=

1. Адресное пространство

2. Глобальные переменные

3. Открытые файлы

4. Дочерние процессы

5. Необработанные аварийные сигналы

6. Сигналы и их обработчики

7. Информация об использовании ресурсов

#Элементы индивидуальные для каждого потока(элементы потока)=

1. Счётчик команд

2. Регистры

3. Стек

4. Состояние

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

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

· б) будет уместна, когда потоки выполняют совместно одну работу.

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

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

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

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

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

Приведем пример использования потоков.

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

Представим, что пользователь пишет книгу. С точки зрения автора проще всего хранить всю книгу в одном единственном файле, чтобы легче было искать отдельные разделы, выполнять глобальную замену и т.п. С другой стороны, можно хранить каждую главу в отдельном файле. Но было бы крайне неудобно хранить каждый раздел и параграф в отдельном файле - в сотни глобальных изменений пришлось бы редактировать сотни файлов. Например, если предполагаемый стандарт ххх был утвержден только перед отправкой книги в печать, придется изменять “Черновой стандарт ххх” на “Стандарт ххх” в последнюю минуту. Эта операция делается одной командой в случае одного файла и, напротив, займет очень много времени, если если придется редактировать каждый из 300 файлов, на которые разбита книга.

Теперь представим себе, что произойдет, если пользователь удалит одно предложение на первой странице документа, в котором 800 страниц. Пользователь перечитал это предложение и решил исправить предложение на 600-ой странице. Он дает текстовому редактору команду перейти на 600 страницу (например, задав поиск фразы, встречающейся только на этой странице). Текстовому редактору придется переформатировать весь документ вплоть до 600-ой странице, поскольку до форматирования он не будет знать, где начинается эта страница. Это может занять достаточно много времени и вряд ли обрадует пользователя.

В этом случае помогут потоки. Пусть текстовый редактор написан в виде двух поточной программы.

· Один поток взаимодействует с пользователем,

· а другой форматирует документ в фоновом режиме.

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

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

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

1. Первый поток взаимодействует с пользователем,

2. второй при необходимости переформатирует документ,

3. а третий периодически сохраняет на диск содержимое оперативной памяти.

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

3)Иерархия процессов, назначение

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

Следует отметить, что в отличии от животного мира у процесса может быть только один родитель и сколько угодно “детей”.

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

Рассмотрим в качестве примера иерархии процессов инициализацию UNIX при запуске.

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

Напротив, в Windows не существует понятия иерархии процессов и все процессы равноправны. Единственное, в чем проявляется что-то вроде иерархии процессов - создание процесса, в котором родительский процесс получает специальный маркер (так называемый дескриптор), позволяющий контролировать дочерний процесс. Но марке можно передавать другому процессу, нарушая иерархию. В UNIX это невозможно.

4) Реализация потоков в пространстве пользователя и в пространстве ядра. Преимущества и недостатки.

Как избежать состязания?

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

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

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

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

· 1. Два процесса не должны одновременно находиться в критических областях.

· 2. В программе не должно бытьпредположенийо скорости или количестве процессоров.

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

· 4. Невозможна ситуация, в которой процесс вечно ждет попадания в критическую область.

Семафо́р — объект, позволяющий войти в заданный участок кода не более чем N потокам. Определение введено Эдсгером Дейкстрой

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

Дейкстра предложил две операции,down и up (обобщения sleep и wakeup).

1) Опе­рация down сравнивает значение семафора с нулем. Если значение семафора больше нуля, операция down уменьшает его(то есть расходует один из сохраненных сигналов активации)и просто возвращает управление. Если значение семафора равно нулю, процедура down не возвращает управление процессу, а процесс переводится в состояние ожидания. Все операции проверки значения семафора, его изменения и перевода процесса в состояние ожидания выполняютсякак единое и неделимое элементарное действие.Тем самым гарантируется, что после начала операции ни
один процесс не получит доступа к семафору до окончания или блокирования операции.Элементарность операции чрезвычайно важна для разрешения пробле­мы синхронизации и предотвращения состояния состязания.

2) Операция up увеличивает значение семафора. Если с этим семафором связаны один или несколько ожидающих процессов, которые не могут завершить более раннюю операцию down, один из них выбирается системой (например, случайным образом) и ему разрешается завершить свою операцию down. Таким образом, после
операции up, примененной к семафору, связанному с несколькими ожидающими процессами, значение семафора так и останется равным 0, но число ожидающих процессов уменьшится на единицу.Операция увеличения значения семафора и активизации процесса тоже неделима.
Ни один процесс не может быть блокирован во время выполнения операции up.

Иногда используется упрощенная версия семафора, называемаямьютексом (mutex, сокращение от mutual exclusion — взаимное исключение).
Мьютекс не способен считать, он может лишь управлять взаимным исключением доступа к совместно используемым ресурсам или кодам.
Реализация мьютекса проста и эффективна, что делает использование мьютексов особенно полезным в случае потоков, действующих только в пространстве пользователя.

Мьютекс — переменная, которая может находиться в одном из двух состояний: блокированном или неблокированном. Поэтому для описания мьютекса требуется всего один бит, хотя чаще используется целая переменная, у которой 0 означает неблокированное состояние, а все остальные значения соответствуют блокированному состоянию. Значение мьютекса устанавливается двумя процедурами. Если поток (или процесс) собирается войти в критическую область, он вызывает процедуру mutex_lock(). Если мьютекс не заблокирован (то есть вход в критическую область разрешен), запрос выполняется и вызывающий поток может попасть в критическую область.

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

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

Чтобы упростить написание программ, в 1974 году Хоар (Ноаге) [155] и Бринч Хансен (Brinch Hansen) [43] предложилипримитив синхронизации более высо­кого уровня, называемый монитором.
Их предложения несколько отличались друг от друга, как мы увидим дальше.

Монитор — набор процедур, переменных и дру­гих структур данных, объединенных в особый модуль или пакет.

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

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

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

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

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

Решение заключается во введении переменных состояния и двух операций, wait и signal. Когда процедура монитора обнаруживает, что она не в состоянии продолжать работу (например, производитель выясняет, что буфер заполнен), она выполняет операцию wait на какой-либо переменной состояния, скажем, full. Это приводит к блокировке вызывающего процесса и позволяет другому процессу войти в монитор.
Другой процесс, в нашем примере потребитель может активизировать ожидающего напарника, например, выполнив операцию signal на той переменной со­стояния, на которой он был заблокирован.

Чтобы в мониторе не оказалось двух активных процессов одновременно, нам необходимо правило, определяющее по­следствия операции signal. Хоар предложил запуск «разбуженного» процесса и остановку второго.

Бринч Хансен предложил другое решение:процесс, выполнивший signal, должен немедленно покинуть монитор. Иными словами, операция signal выполняется только в самом конце процедуры монитора. Мы будем использовать это решение, поскольку оно в принципепроще и к тому же легче в реализации.

Если операция signal выполнена на переменной, с которой связаны несколько за­блокированных процессов, планировщик выбирает и «оживляет» только один из них. Кроме этого, существует третье решение, не основывающееся на предположениях Хоара и Бринча Хансена: позволить процессу, выполнившему signal, продолжать работу и запустить ждущий процесс только после того, как первый процесс покинет монитор.

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

Запрещение прерываний.

Самое простое решение заключается в запрещении всех прерываний при входе процесса в критическую область и разрешении прерываний при выходе из области.Если прерывания запрещены, то невозможно прерывание по таймеру. Поскольку процессор переключается с одного процесса на другой только по прерыванию. то отключение прерываний исключает передачу процессора другому процессу. Таким образом, запретив прерывания, процесс может спокойно считывать и сохранять совместно используемые данные, не опасаясь вмешательства другого процесса.
И все же было бы неразумно давать пользовательскому процессу возможность запрета прерываний. Представим, что процесс отключил все прерывания и в результате какого-либо сбоя не включил их обратно. Операционная система на этом моменте может закончить свое существование =)).
К тому жев многопроцессорной системе запрещение прерываний повлияет только на тот процессор, который выполнит инструкцию disable.Остальные процессоры продолжат работу и получат доступ к разделенным данным.

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

Переменные блокировки.

Теперь попробуем найтипрограммное решение.

Рассмотрим одну совместную переменную блокировки, изначально равную 0. Если процесс хочет попасть в критическую область, он предварительно считывает значение переменной блокировки. Если переменная равна 0, то процесс заменят ее значение на 1 и входит в критическую область. Если же переменная равна 1, то процесс ждет, пока ее значение сменится на 0. Таким образом, 0 означает, что ни одного процесса в критической области нет, а 1 означает, что какой либо процесс находится в критической области.
У этого метода есть свои проблемы. Представим, что один процесс считывает переменную блокировки, обнаруживает, что она равна 0, но прежде, чем он успевает заменить ее на 1, управление получает другой процесс, успешно заменяющий ее на 1. Когда первый процесс снова получит управление, то он тоже заменит значение переменной блокировки на 1 и два процесса одновременно окажутся в критических областях.

Строгое чередование

На рисунке =

1. целая переменная turn, изначально равная 0, отслеживает, чья очередь входить в критическую область.

2. Вначале процесс 0 проверяет значение turn, считывает 0 и входит в критическую область(*см. примечание ниже)

3. Процесс 1 также считывает значение turn, считывает 0 и после этого входит в цикл, непрерывно проверяя, когда значение turn будет равно 1.

*примечание:
-----------------------------------
на мой взгляд на картинке выше

Опечатка

,чтобы задуманное выполнилось(Вначале процесс 0 проверяет значение turn, считывает 0 и входит в критическую область) необходимо в левом цикле (а) вместо

?

while (turn!=0) ; // неправильно! (по-моему)

написать =

?

while (turn!=1) ; // правильно (по-моему)

так как именно во втором случаепроцесс 0при изначальном turn=0 сможет миновать цикл
-----------------------------------

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

Алгоритм Петерсона

Перед тем как обратиться к совместно используемым переменным(то есть перед тем, как войти в критическую область), процесс вызывает процедуру enter_region() со своим номером (0 или 1) в качестве параметра.
Поэтому процессу при необходимости придется подождать, прежде чем входить в критическую область.
После выхода из критической области процесс вызывает процедуру leave_region, чтобы обозначить свой выход и тем самым разрешить другому процессу вход в критическую область.

Команда TSL

Рассмотрим решение, требующее аппаратного обеспечения.
Многие компьютеры, особенно разработанные с расчетом на несколько процессоров, имеют команду
TSL RX.LOCK
(Test and Set Lock), которая действует следующим образом-
В регистр RX считывается содержимое слова памяти lock, а в ячейке памяти lock хранится некоторое ненулевое значение.
Гарантируется, что операция считывания слова и сохранения неделима - другой процесс не может обратиться к слову в памяти, пока команда не выполнена. Процессор, выполняющий команду TSL, блокирует шину памяти, чтобы остальные процессоры не могли обратиться к памяти.
Рассмотрим пример использования команды TSL для взаимного исключения.

Прежде чем попасть в критическую область, процесс вызывавает процедуру enter_region, которая выполняет активное ожидание вплоть до снятия блокировки, затем она устанавливает блокировку и возвращается.
При выходе из критической области процесс вызывает процедуру leave_region, помещающую ноль в переменную lock. Как и в остальных способах решения проблемы критической области,для корректной работы процесс должен вызвать эти процедуры своевремнно, в противном случае взаимное исключение не удастся.

15) Планирование процессов. Задачи алгоритмов планирвоания.

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

Планирование- это разделение вычислительных ресурсов системы между процессами и потоками.

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

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

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

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

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

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

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

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

· 1. Системы пакетной обработки данных.

· 2. Интерактивные системы.

· 3. Системы реального времени.

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

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

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

Задачи алгоритмов планирования.

Чтобы разработать алгоритм планирования, необходимо иметь представление о том, что должен делать хороший алгоритм. Некоторые задачи зависят от среды (системы пакетной обработки, интерактивные или реального времени), но есть задачи, одинаковые во всех системах.

Список задач

представлен ниже .

# Для всех типов систем=

1. Справедливость - предоставление каждому процессу справедливой доли процессорного времени.

2. Принудительное применение политики - контроль за выполнением принятой политики.

3. Баланс - поддержка занятости всех частей системы.

# Для систем пакетной обработки данных=

1. Пропускная способность- максимальное количество задач в час

2. Оборотное время - минимизация времени, затрачиваемого на ожидание, обслуживание и обработку задачи.

3. Использование процессора - поддержка постоянной занятости процессора

# Для интерактивных систем=

1. Время отклика- быстрая реакция на запросы

2. Соразмерность - выполнение пожеланий пользователя

# Для систем реального времени=

1. Окончание работы к сроку - предотвращение потери данных

2. Предсказуемость - предотвращение деградации качества в мультимедийных системах

16) Активация планировщика (когда выполняется планирование).

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

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

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