Состояния процессов в UNIX

Планирование процессов

Средства взаимодействия процессов в стандарте POSIX

Десятилетия успешного использования UNIX выявили, тем не менее, ряд недостатков в исходной архитектуре этой системы. Одним из самых заметных пробелов была явная слабость механизма синхронизации процессов, основанного фактически лишь на сигналах и на функции wait. На практике в большинстве реализаций UNIX вводились дополнительные, более удобные средства межпроцессного взаимодействия, однако возникала проблема несовместимости таких средств для разных версий UNIX. Разнобой был пресечен в начале 90-х годов с выработкой стандарта POSIX, объединившего все лучшее, что к тому времени было предложено в разных версиях UNIX.

К средствам, которые, согласно POSIX, должна поддерживать любая современная реализация UNIX, относятся, в частности:

· сигналы;

· безымянные и именованные каналы;

· очереди сообщений;

· семафоры;

· совместно используемые (разделяемые) области памяти.

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

UNIX является многозадачной системой с вытесняющей приоритетной диспетчеризацией.

Диаграмма основных состояний процесса, показанная на рис. 4‑1, в случае UNIX может быть уточнена так, как показано на рис. 4‑2.

Рис. 4‑2

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

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

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

Из сказанного можно сделать два важных вывода.

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

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

В диаграмме на рис. 4‑2 не учтены еще некоторые состояния, в которых может находиться процесс в UNIX. К их числу относятся состояние старта (процесс только что создан, но еще не готов к выполнению), состояние зомби (см. п. 4.6.1) и состояние приостановки, в которое переходит процесс, получивший сигнал SIGSTOP (см. п. 4.6.4).

Дата добавления: 2014-01-20