Восстановление после тупиков

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

Самый простой метод восстановления - это принудительное завершение всех процессов и запуск операционной системы заново.

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

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

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

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

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

УПРАВЛЕНИЕ ПРОЦЕССОРОМ

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

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

Диспетчеризация процессов

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

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

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

- приоритетность процессов. Для процессов более высокого приоритета должны создаваться лучшие условия выполнения, чем для процессов более низкого приоритета;

- насколько часто при выполнении процесса возникают прерывания по отсутствию нужных страниц. Можно полагать, что процессы, генерирующие малое число прерываний по отсутствию нужных страниц, уже собрали свои рабочие множества в основной памяти, тогда как процессы, для которых характерно большое количество прерываний, пока еще не сформировали свои рабочие множества. Обычно считается наиболее целесообразным оказывать предпочтение процессам, которые сформировали свои рабочие множества. Однако существует и другая точка зрения - предпочтение должно оказываться процессам с высокими частотами прерываний по отсутствию нужных страниц, поскольку они занимают ЦП лишь короткие промежутки времени перед генерацией запроса на ввод-вывод;

- насколько часто данный процесс приостанавливается из-за переключения на процесс более высокого приоритета. Часто приостанавливаемым процессам следует создавать менее благоприятные условия для продолжения работы. Это объясняется тем, что для запуска подобного процесса операционной системе каждый раз приходится идти на определенные накладные расходы, а короткое время работы процесса перед приостановкой их не оправдывает;

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

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

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

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

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

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

Приоритеты

Как уже отмечалось, приоритетность процесса является одним из критериев при выделении центрального процессора процессу для его исполнения. Система может присваивать приоритеты автоматически или они могут назначаться извне. Приоритеты могут быть заслуженными («заработанными») или купленными. Они могут быть либо статическими, либо динамическими. Они могут присваиваться по какому-то рациональному принципу или произвольно назначаться в ситуациях, когда системному механизму необходимо каким-то образом различать процессы, однако он не знает, какой из них в действительности более важен.

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

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

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

Концепция приоритетов, как правило, весьма существенна, но требует некоторых расходов. Для определения приоритета можно использовать много других факторов помимо тех, кот­орые перечислены в контексте процесса. Среди них - время создания процесса, время появления работы, вызвавшей образование процесса, заказанное время обслуживания, использованное время обслуживания, время, в течение которого процесс не обслуживался, объем или вид других ресурсов, заказанных или использованных процессом. Эти факторы можно учитывать различными способами, и, следовательно, существует большое число возможных дисциплин диспетчеризации.

Не нашли, что искали? Воспользуйтесь поиском по сайту: