русс | укр

Языки программирования

ПаскальСиАссемблерJavaMatlabPhpHtmlJavaScriptCSSC#DelphiТурбо Пролог

Компьютерные сетиСистемное программное обеспечениеИнформационные технологииПрограммирование

Все о программировании


Linux Unix Алгоритмические языки Аналоговые и гибридные вычислительные устройства Архитектура микроконтроллеров Введение в разработку распределенных информационных систем Введение в численные методы Дискретная математика Информационное обслуживание пользователей Информация и моделирование в управлении производством Компьютерная графика Математическое и компьютерное моделирование Моделирование Нейрокомпьютеры Проектирование программ диагностики компьютерных систем и сетей Проектирование системных программ Системы счисления Теория статистики Теория оптимизации Уроки AutoCAD 3D Уроки базы данных Access Уроки Orcad Цифровые автоматы Шпаргалки по компьютеру Шпаргалки по программированию Экспертные системы Элементы теории информации

Монопольные ресурсы. Проблема тупиков. Дисциплины распределения ресурсов. Поиск тупиков и их уничтожение

Монопольные ресурсы (принтеры, магнитные ленты, каналы связи)– это ресурсы  неперераспределяемые(ресурс не может быть отобран без фатальных для процесса  последствий) и неразделяемые(один и тот же ресурс в одинаковые моменты времени не могут использовать два процесса). Данные ресурсы можно использовать повторно, т.е. ресурсы после их использования процессами не пропадают и не  убывают,  а  могут быть  использованы  другим процессом. Тупики – это проблема синхронизации.

Пример тупика. Пусть двум процессам, выполняющимся в режиме мультипрограммирования, для выполнения их работы нужно два ресурса, например, принтер и диск. На рисунке 2.6,а показаны фрагменты соответствующих программ. И пусть после того, как процесс А занял принтер (установил блокирующую переменную), он был прерван. Управление получил процесс В, который сначала занял диск, но при выполнении следующей команды был заблокирован, так как принтер оказался уже занятым процессом А. Управление снова получил процесс А, который в соответствии со своей программой сделал попытку занять диск и был заблокирован: диск уже распределен процессу В. В таком положении процессы А и В могут находиться сколь угодно долго.

Проблема тупиков включает в себя следующие задачи:

предотвращение тупиков,
распознавание тупиков,
восстановление системы после тупиков.

Тупики могут быть предотвращены на стадии написания программ, то есть программы должны быть написаны таким образом, чтобы тупик не мог возникнуть ни при каком соотношении взаимных скоростей процессов. В некоторых случаях, когда тупиковая ситуация образована многими процессами, использующими много ресурсов, распознавание тупика является нетривиальной задачей. Существуют формальные, программно-реализованные методы распознавания тупиков, основанные на ведении таблиц распределения ресурсов и таблиц запросов к занятым ресурсам. Анализ этих таблиц позволяет обнаружить взаимные блокировки. Если же тупиковая ситуация возникла, то не обязательно снимать с выполнения все заблокированные процессы. Можно снять только часть из них, при этом освобождаются ресурсы, ожидаемые остальными процессами, можно вернуть некоторые процессы в область свопинга, можно совершить "откат" некоторых процессов до так называемой контрольной точки, в которой запоминается вся информация, необходимая для восстановления выполнения программы с данного места. Контрольные точки расставляются в программе в местах, после которых возможно возникновение тупика. Предотвратить тупик можно выделяя ресурсы последовательно(Любыми  ресурсами может одновременно пользоваться только один процесс), залпово(Процесс должен запрашивать/освобождать все используемые им ресурсы сразу. Эта стратегия позволяет параллельно выполняться процессам, использующим непересекающиеся  подмножества  ресурсов), иерархически(Все  классы ресурсов разбиваются по уровням с номерами от 1 до N, каждый уровень содержит только один класс.  Процесс имеет право запрашивать ресурсы только из классов с более высокими номерами,  чем у тех,  которыми он уже  владеет. Эта стратегия также предотвращает возникновение тупиков. В каждый момент времени в системе один или несколько процессов имеют класс закрепленных за ними ресурсов выше,  чем у других.  Эти процессы, обладающие ресурсами высокого уровня,  могут беспрепятственно выполняться и завершиться без блокировки.  Следовательно,  в каждый момент времени имеется хотя бы один способный к  выполнению  процесс.  Если  не будут поступать новые процессы,  то все процессы, уже имеющиеся в системе,  в конце концов завершатся), по предварительным заявкам. Эта стратегия названа так потому, что действия ОС напоминают действия банкира, выдающего ссуды клиентам).

Задача «Обедающие философы». Пять философов сидят за круглым  столом,  в  центре  которого стоит  блюдо с рисом.  Между каждой парой философов лежит палочка для еды,  палочек,  следовательно, тоже пять. Для того, чтобы начать  есть,  философ должен взять две палочки - слева и справа от себя. Таким образом, если один из философов ест, его соседи справа  и слева лишены такой возможности,  так как им недостает палочек. Каждый философ "работает" по зацикленному алгоритму: сначала он некоторое время думает, затем берет палочки и ест, затем опять думает и т.д.  Временные интервалы мышления и еды случайны, действия философов,  следовательно не синхронизированы. Ничего не говорится в условии о том,  каким образом философ берет  палочки наша задача как раз и состоит в том, чтобы обеспечить такую стратегию выделения палочек, которая бы исключала тупики и голодание.

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

Алгоритм «Банкира».

1.Клиент делает заем для совершения сделки, которая будет завершена за конечный промежуток времени.
2.Клиент должен заранее указать максимальную "потребность" во флоринах для этой сделки.
3.Пока "заем" не превышает заранее установленную "потребность", клиент может увеличивать или уменьшать свой заем флорин за флорином.
4.Клиент, который просит увеличить его текущий заем, обязуется принимать без недовольства следующий ответ: "Если бы я дал вам запрашиваемый флорин, вы еще не превысили бы свою установленную потребность, и поэтому вы имеете право на следующий флорин. Однако в настоящий момент мне, по некоторым причинам, неудобно его дать, но я обещаю вам флорин в должное время".
5.Гарантия для клиента в том, что этот момент действительно наступит, основана на предусмотрительности банкира и на том факте, что остальные клиенты подчиняются тем же условиям, что и он сам: как только клиент получает флорин, он приступает к своей сделке с ненулевой скоростью, т. е. в конечный промежуток времени он или запросит новый флорин, или возвратит флорин, или закончит сделку, что означает возвращение всего займа (флорин за флорином).

Просмотров: 6175

Вернуться в оглавление:Шпаргалки по компьютеру




Карта сайта Карта сайта укр


Уроки php mysql Программирование

Онлайн система счисления Калькулятор онлайн обычный Инженерный калькулятор онлайн Замена русских букв на английские для вебмастеров Замена русских букв на английские

Аппаратное и программное обеспечение Графика и компьютерная сфера Интегрированная геоинформационная система Интернет Компьютер Комплектующие компьютера Лекции Методы и средства измерений неэлектрических величин Обслуживание компьютерных и периферийных устройств Операционные системы Параллельное программирование Проектирование электронных средств Периферийные устройства Полезные ресурсы для программистов Программы для программистов Статьи для программистов Cтруктура и организация данных


 


Полезен материал? Поделись:

Не нашли то, что искали? Google вам в помощь!

 
 

© life-prog.ru При использовании материалов прямая ссылка на сайт обязательна.