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

Question

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

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

Answer 1

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

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

Answer 2

Если запущенный процесс блокирует ввод-вывод

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

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

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

Answer 3

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

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

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

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

Answer 4

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

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

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

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