Несмотря на самостоятельность каждого процесса, наличие собственного счетчика команд и внутреннего состояния, процессам зачастую необходимо взаимодействовать с другими процессами. Один процесс может генерировать выходную информацию, ис¬пользуемую другими процессами в качестве входной информации. В команде оболочки
cat chapter1 chapter2 chapter3 | grep tree
первый процесс, запускающий программу cat, объединяет и выдает на выходе содержимое трех файлов. Второй процесс, запускающий программу grep, выбирает все строки, в которых содержится слово «tree». В зависимости от относительной скорости этих двух процес¬сов (которая зависит от двух факторов: относительной сложности программ и количества выделяемого каждому из них времени ра¬боты центрального процессора) может получиться так, что про¬грамма grep готова к работе, но ожидающие ее входные данные от¬сутствуют. Тогда она должна блокироваться до поступления вход¬ных данных.
Процесс блокируется из-за того, что, по логике, он не может продолжаться, как правило, потому что ожидает недоступных в настоящий момент входных данных. Может случиться и так, что останавливается тот процесс, который в принципе готов к работе и может быть запущен, а причина кроется в том, что операционная система решила на некоторое время выделить центральный процес¬сор другому процессу. Эти два условия полностью отличаются друг от друга. В первом случае приостановка порождена какой-нибудь проблемой (вы не можете обработать пользовательскую командную строку, пока она не будет введена). Во втором случае на первый план выступает техническая сторона вопроса (не хватает централь¬ных процессоров, чтобы каждому процессу выделить собственный процессор). На рис. 33 показана диаграмма, отображающая три со¬стояния, в которых может находиться процесс:
• выполняемый (в данный момент использующий централь¬ный процессор);
• готовый (работоспособный, но временно приостановлен¬ный, чтобы дать возможность выполнения другому про¬цессу);
• заблокированный (неспособный выполняться, пока не возникнет какое-нибудь внешнее событие).
Логически первые два состояния похожи друг на друга. В обоих случаях процесс желает выполняться, но во втором состоя¬нии временно отсутствует доступный для этого процессор. Третье состояние коренным образом отличается от первых двух тем, что процесс не может выполняться, даже если процессору кроме него больше нечем заняться.
Как показано на рисунке, между этими тремя состояниями могут быть четыре перехода. Переход 1 происходит в том случае, если операционная система определит, что процесс в данный мо¬мент выполняться не может. В некоторых системах для перехода в заблокированное состояние процесс может осуществить такой си¬стемный вызов, как pause. В других системах, включая UNIX, когда процесс осуществляет чтение из канала или специального файла (например, с терминала) и доступные входные данные отсутствуют, процесс блокируется автоматически.
Переходы 2 и 3 вызываются планировщиком процессов, ко¬торый является частью операционной системы, без какого-либо оповещения самого процесса. Переход 2 происходит, когда плани¬ровщик решит, что выполняемый процесс продвинулся достаточно далеко и настало время позволить другому процессу получить долю рабочего времени центрального процессора. Переход 3 происходит, когда все другие процессы получили причитающуюся им долю времени и настал момент предоставить центральный процессор первому процессу для возобновления его выполнения. Вопрос пла¬нирования, то есть решение, какой именно процесс, когда и сколько времени должен выполняться, играет весьма важную роль. В по¬пытках сбалансировать конкурирующие требования соблюдения эффективности системы в целом и справедливого отношения к от¬дельному процессу было изобретено множество алгоритмов.
Переход 4 осуществляется в том случае, если происходит внешнее событие, ожидавшееся процессом (к примеру, поступле¬ние входных данных). Если к этому моменту нет других выполняе¬мых процессов, будет вызван переход 3 и процесс возобновится. В противном случае ему придется немного подождать в состоянии готовности, пока не станет доступен центральный процессор и не придет его очередь.
Использование модели процесса облегчает представление о том, что происходит внутри системы. Некоторые процессы запус¬кают программу, выполняющую команды, введенные пользовате¬лем. Другие процессы являются частью системы, справляясь с та¬кими задачами, как выполнение запросов на обслуживание файлов или управление деталями работы дискового или ленточного при¬вода. Когда происходят дисковые прерывания, система принимает решение остановить выполнение текущего процесса и запустить процесс работы с диском, заблокированный в ожидании этого пре¬рывания. Таким образом, вместо того чтобы думать о прерываниях, мы можем думать о пользовательских процессах, процессах работы с диском, процессах работы с терминалом и т. д., которые блоки-руются, когда ожидают каких-то событий. Когда считана информа¬ция с диска или набран символ, процесс, ожидающий это событие, разблокируется и получает право на возобновление выполнения.
В результате такого представления возникает модель, пока¬занная на рис. 34. На этом рисунке самым нижним уровнем опера¬ционной системы является планировщик, над которым изображен ряд процессов. Вся обработка прерываний и подробности действий, запускающих и останавливающих процессы, здесь скрыты под тем, что называется планировщиком, для реализации которого исполь¬зуется сравнительно небольшой объем кода. Вся остальная часть операционной системы неплохо структурирована в виде процессов. Но такой структурой обладает сравнительно небольшое количество настоящих систем.
Оставить комментарий