Слишком сложно? Тогда запросите консультацию специалиста!
Наша компания занимается тем, что помогает студентам выполнять различные учебные работы на заказ. Вы можете ознакомиться с перечнем выполняемых работ, а так же с их стоимостью на странице с ценами.
Пусть некоторый процесс ПР1 должен обменяться сообщениями с процессом ПР2 и каждый из них запрашивает некоторый ресурс R, причем ПР1 требует три единицы этого ресурса для своей работы, а ПР2 – две единицы и только на время обработки сообщения. Всего же имеются только четыре единицы ресурса R. Запрос ресурса можно реализовать через соответствующий монитор с процедурами REQUEST(R,N) – запрос N единиц ресурса R и RELEASE(R,N) – освобождение, возврат N единиц ресурса R. Обмен сообщениями будем осуществлять через почтовый ящик MB. Фрагменты программ ПР1 и ПР2 приведены в листинге. 9.3.
Листинг 9.3.Пример тупика на CR- и SR-pecypcax
. . .
. . .
ПР1: REQUEST (R, 3);
SEND_MESSAGE (ПР2, сообщение, MB);
WAIT ANSWER (ответ, MB);
. . .
. . .
RELEASE (R, 3);
. . .
. . .
. . .
. . .
ПР2: WAIT_MESSAGE (ПР1, сообщение, MB);
REQUEST (R, 2);
ОБРАБОТКА СООБЩЕНИЯ;
RELEASE(R, 2);
SEND_ANSWER(ответ, MB);
Эти два процесса всегда будут попадать в тупик. Процесс ПР2, если будет выполняться первым, сначала ожидает сообщения от процесса ПР1, после чего будет заблокирован при запросе ресурса R, часть которого будет уже отдана ПР1. Процесс ПР1, завладев частью ресурса R, будет заблокирован на ожидании ответа от ПР2, которого никогда не получит, так как для этого ПР2 нужно получить ресурс R, находящийся в распоряжении ПР1. Тупика можно избежать лишь при условии, что на время ожидания ответа от ПР2 процесс ПР1 будет отдавать хотя бы одну единицу ресурса R, которыми он сейчас владеет. В данном примере, как и в предыдущем, причиной тупика являются ошибки программирования.
