Средства взаимодействия процессов в стандарте posix
Десятилетия успешного использования UNIXвыявили, тем не менее, ряд недостатков в исходной архитектуре этой системы. Одним из самых заметных пробелов была явная слабость механизма синхронизации процессов, основанного фактически лишь на сигналах и на функцииwait. На практике в большинстве реализацийUNIXвводились дополнительные, более удобные средства межпроцессного взаимодействия, однако возникала проблема несовместимости таких средств для разных версийUNIX. Разнобой был пресечен в начале 90-х годов с выработкой стандартаPOSIX, объединившего все лучшее, что к тому времени было предложено в разных версияхUNIX.
К средствам, которые, согласно POSIX, должна поддерживать любая современная реализацияUNIX, относятся, в частности:
сигналы;
безымянные и именованные каналы;
очереди сообщений;
семафоры;
совместно используемые (разделяемые) области памяти.
Сигналы и каналы были рассмотрены выше. Использование семафоров, очередей сообщений и разделяемой памяти дает примерно те же функциональные возможности, что аналогичные средства Windows, хотя и содержит много интересных особенностей, которые придется, к сожалению, оставить за рамками данного курса.
Планирование процессов
Состояния процессов в unix
UNIXявляется многозадачной системой с вытесняющей приоритетной диспетчеризацией.
Диаграмма основных состояний процесса, показанная на рис. 4‑1, в случае UNIXможет быть уточнена так, как показано на рис. 4‑2.
Рис. 4‑18
Поставим следующий вопрос: в каком состоянии находится процесс, когда он вызвал системную функцию и ядро системы выполняет эту функцию? При описании работы большинства ОС этот вопрос обходят молчанием. В UNIXдается четкий ответ: процесс продолжает работать, но он переходит в режим ядра и выполняет системный код. Системные подпрограммы, работающие в режиме ядра, могут использовать все ресурсы системы. При этом контекст процесса остается доступен, что позволяет при выполнении системной функции использовать память и другие ресурсы процесса.
Возможно, что в ходе выполнения системной функции процесс будет заблокирован и перейдет в состояние сна. После пробуждения он перейдет в состояние готовности. Затем процесс будет выбран для выполнения и перейдет в режим ядра, чтобы завершить выполнение той системной функции, на которой он был заблокирован. После этого процесс должен вернуться в режим задачи, однако сразу после выхода из режима ядра процесс может быть вытеснен, если имеется активный процесс с более высоким приоритетом.
Еще один путь изменения состояния процесса связан с обработкой аппаратного прерывания. При этом обработка прерываний всегда выполняется в режиме ядра. После завершения обработки процессу следовало бы вернуться в режим задачи и продолжить выполнение прорванной программы. Однако и здесь возможны варианты. Если в результате прерывания пробудился более приоритетный процесс или если при обработке прерывания от таймера планировщик выбрал другой процесс для выполнения, то текущий процесс будет вытеснен в момент возврата из режима ядра в режим задачи.
Из сказанного можно сделать два важных вывода.
Процесс, работающий в режиме ядра, не может быть вытеснен ни по истечению кванта времени, ни при активизации более приоритетного процесса. Вытеснение процесса возможно только в момент возврата из режима ядра в режим задачи.
Переход в состояние сна всегда происходит из выполнения в режиме ядра. После пробуждения процесс возвращается в режим ядра через состояние готовности.
В диаграмме на рис. 4‑2 не учтены еще некоторые состояния, в которых может находиться процесс в UNIX. К их числу относятся состояние старта (процесс только что создан, но еще не готов к выполнению), состояние зомби (см. п. 4.6.1) и состояние приостановки, в которое переходит процесс, получивший сигналSIGSTOP(см. п. 4.6.4).