Совместное планирование приостанавливает процессы, когда они выполняют операцию ввода-вывода?

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

[Отредактировано, чтобы заменить «блоки ввода / вывода» на «выполняет запрос ввода / вывода, который не может быть немедленно удовлетворен».]

В действительно «кооперативной» настройке, и если не было никакой аппаратной защиты, процесс, безусловно, мог заблокировать ввод-вывод и не отказаться от управления до тех пор, пока не был выполнен ввод-вывод (или вообще никогда не отказаться от управления). Например, Windows 3.1 была такой: если один пользовательский процесс хотел взять на себя весь компьютер и запретить запуск чего-либо еще, он мог бы.

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

Если запущенный процесс блокируется на I / O

Блокировка ввода-вывода в значительной степени эквивалентна приостановке вашего процесса. В контексте ядра Linux, выполнение некоторого системного вызова IO, такого как, read()приведет к тому, что sysenterобработчик прерываний или триггера вызовет обработку этого ввода-вывода, вызывая в do_sys_read()конечном счете. Здесь, если текущий запрос не может быть немедленно удовлетворен, вызывается функция, sched()которая затем может выполнить другой процесс.

В контексте кооперативной системы я ожидал бы, что когда вы совершаете системный вызов по какой-то причине ввода-вывода, если запрос не может быть удовлетворен, ядро ​​выбирает другую задачу и выполняет ее. Этот документ дает некоторую предысторию - в основном, если вы ждали IO, вы могли бы быть навсегда в ожидании этого IO. Идея совместного планирования заключается в том, что вы часто вызываете sched()или эквивалентный метод relinquish-the-cpu, если выполняете задачи с интенсивным использованием процессора.

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

В модели совместного планирования (предпочтительно cooperative multitasking) нет концепции планировщика в том смысле, что операционная система не имеет никакого контроля над продолжительностью процесса.

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

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

РЕДАКТИРОВАТЬ: Мой ответ был основан на графике, как описано в его первоначальном виде (годы назад: P). Как прокомментировал Жиль, некоторые системы все еще используют совместное планирование. И есть планировщик. Я не уверен, что эти системы используют COS в чистом и оригинальном виде.

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

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

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

Как пояснил Жиль, упреждение - это ограничение архитектуры системы, которое предотвращает прерывание по времени активной задачи и принудительное переключение контекста.