21. Кооперативная многопроцессность и вытесняющая многопроцессность

Кооперативная многопроцессность

Данная схема планирования процессов основана на том, что переключение процессов происходит по инициативе активного процесса.

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

1.Он передает управление на следующий активный процесс.

2.Текущий процесс остается активным, и через некоторое время снова получит управление.

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

Для того, чтобы планировщик смог произвести указанные действия, очевидно, ему

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

Кроме стека процесса, описатель должен содержать еще некоторые поля. Как минимум, он должен содержать указатель на следующий активный процесс. Система должна хранить указатели на текущий процесс и на конец списка. При этом планировщик переставляет текущий процесс в конец списка, а текущим делает следующий за ним в списке. Все вновь активизируемые процессы также ставятся в конец списка. Часто в литературе такой список называют очередью процессов (process queue).

Плюсы:

1.простота отладки;

2.высокая эффективность (скорость работы) планировщика;

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

Минусы:

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

2.злонамеренный процесс может захватить управление и никому не отдавать его (не вызывать планировщик);

3.такая схема непригодна для систем реального времени — нет гарантированного времени реакции на внешнее событие.

Вытесняющая многозадачость

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

1.Каждому процессу выделяется квант времени.

2.Если процесс не освободил процессор в течение этого кванта, то его снимают и переставляют в конец очереди. При этом все готовые к исполнению процессы более или менее равномерно получают управление.

Этот механизм, называемый time slicing или разделение времени, реализован практически во всех современных ОС. Вытесняющая многопроцессность противопоставляется кооперативной, где переключение происходит только по инициативе самой задачи.

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

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

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