Околения компьютеров
 Скачать 1.67 Mb.
|
|
1 – это аналог операции up. Теперь представим себе, что очередной посетитель обнаруживает, что свободных тележек нет – он вынужден блокироваться на входе в ожидании появления тележки. Когда один из посетителей, находящихся в торговом зале, покидает его, посетитель, ожидающий тележку, разблокируется, забирает тележку и проходит в зал. Таким образом, наш семафор в виде тележек позволяет находиться в торговом зале (аналоге критической секции) не более чем N посетителям одновременно. Положив N = 1, получим реализацию взаимного исключения. Семафор, начальное (и максимальное) значение которого равно 1, называется двоичным семафором (так как имеет только 2 состояния: 0 и 1). Использование двоичного семафора для организации взаимного исключения проиллюстрировано на Рис. 6. процесс 1 int semaphore; … down(semaphore); /* критическая секция процесса 1 */ … up(semaphore); … процесс 2 int semaphore; … down(semaphore); /* критическая секция процесса 2 */ … up(semaphore); … Рис. 6 Взаимное исключение с использованием семафора Семафоры представляют собой мощное средство синхронизации, однако программирование с использованием семафоров является достаточно тяжелой задачей, причем незаметная на первый взгляд логическая ошибка может привести к образованию тупиковых ситуаций или нарушению условий синхронизации. С целью облегчить написание корректных программ были предложены более высокоуровневые средства синхронизации, которые мы рассмотрим далее. Мониторы. Идея монитора была впервые сформулирована в 1974 г. Хоаром. В отличие от других средств, монитор представляет собой языковую конструкцию, т.е. некоторое средство, предоставляемое языком программирования и поддерживаемое компилятором. Монитор представляет собой совокупность процедур и структур данных, объединенных в программный модуль специального типа. Постулируются три основных свойства монитора: 1. Структуры данных, входящие в монитор, могут быть доступны только для процедур, входящих в этот монитор (таким образом, монитор представляет собой некоторый аналог объекта в объектно- ориентированных языках и реализует инкапсуляцию данных) 2. Процесс «входит» в монитор путем вызова одной из его процедур 3. В любой момент времени внутри монитора может находиться не более одного процесса. Если процесс пытается попасть в монитор, в котором уже находится другой процесс, он блокируется. Таким образом, чтобы защитить разделяемые структуры данных, их достаточно поместить внутрь монитора вместе с процедурами, представляющими критические секции для их обработки. Подчеркнем, что монитор представляет собой конструкцию языка программирования, и следовательно, компилятору известно о том, что входящие в него процедуры и данные имеют особую семантику, поэтому первое условие может проверяться еще на этапе компиляции. Кроме того, код для процедур монитора тоже может генерироваться особым образом, чтобы удовлетворялось третье условие. Поскольку организация взаимного исключения в данном случае возлагается на компилятор, количество программных ошибок, связанных с организацией взаимного исключения, сводится к минимуму. Дополнительная синхронизация: переменные-условия. Помимо обычных структур данных, мониторы могут включать в себя специальные переменные-условия, на которых определены операции wait и signal. Они используются для синхронизации. Если процесс, находящийся внутри монитора (т.е. исполняющий одну из его процедур), обнаруживает, что логически он не может продолжать выполнение, пока не выполнится определенное условие (например, буфер для записи данных переполнился), он вызывает операцию wait над определенной переменной-условием. При этом его дальнейшее выполнение блокируется, и это позволяет другому процессу, ожидающему входа в монитор, попасть в него. В дальнейшем, если этот другой процесс произведет некоторые действия, которые приведут к изменению обстоятельств (в нашем примере – считает часть данных из буфера), он должен вызвать для соответствующей переменной-условия операцию signal, что позволит разблокировать ожидающий процесс. Тонкость заключается в том, что разблокированный процесс, как и тот, кто его разблокировал, должен оказаться внутри монитора, но нахождение двух процессов внутри монитора одновременно невозможно по определению. Хоар постулировал, что в этом случае процесс, вызвавший signal, приостанавливается. Хансен в своей модификации мониторов в 1975 г. предложил более простое дополнительное условие: вызов signal должен быть самым последним внутри процедуры монитора, чтобы процесс немедленно после его выполнения покинул монитор. Заметим, что переменные-условия используются в мониторах не для организации взаимного исключения (оно постулируется самим определением монитора), а для дополнительной синхронизации процессов. В нашем примере разделяемый ресурс – буфер для чтения/записи охраняется от одновременного доступа по чтению и по записи самим монитором, а переменная-условие предохраняет пишущий процесс от затирания ранее записанных данных. Несомненным достоинством мониторов является то, что взаимное исключение здесь организуется автоматически, что существенно упрощает программирование и снижает вероятность ошибок. Недостатком же является то, что, как уже говорилось, монитор – это языковая конструкция. Следовательно, если язык программирования не содержит таких конструкций (а для большинства распространенных языком это так и есть), программист не может ею воспользоваться. В то же время семафоры, например, являются средством ОС, и если соответствующая ОС поддерживает семафоры, программист может их использовать независимо от того, на каком языке он пишет программы. Мониторы реализованы в некоторых языках программирования, таких как Concurrent Euclid, Concurrent Pascal, Modula-2, Modula-3, однако эти языки не слишком распространены. Обмен сообщениями. Общей проблемой и для мониторов, и для семафоров является то, что их реализация существенно опирается на предположение, что мы имеем дело либо с однопроцессорной системой, либо с многопроцессорной системой, где все процессоры имеют доступ к общей памяти. Однако в случае распределенной системы, где каждый процессор имеет прямой доступ только к своей памяти, такие средства не подходят. Более общим средством, решающим проблему синхронизации как для однопроцессорных систем и систем с общей памятью, так и для распределенных, является обмен сообщениями. Обмен сообщениями представляет собой средство, которое может быть использовано как для синхронизации, в частности для организации взаимного исключения, так и для обмена информацией между взаимосвязанными процессами, выполняющими общую работу. Рассмотрим общую концепцию обмена сообщениями. Основная функциональность реализуется двумя примитивами, реализующими, соответственно, посылку и прием сообщения: send(destination, message) receive(source, message) Как и семафоры, и в отличие от мониторов, эти примитивы являются системными вызовами, а не конструкциями языка. Рассмотрим основные особенности, которыми может обладать та или иная система обмена сообщениями. Синхронизация. Сам смысл обмена сообщениями предполагает определенную синхронизацию между процессом-отправителем и процессом-получателем, так как сообщение не может быть получено до того, как оно послано. Возникает вопрос, что происходит, если один процесс хочет получить сообщение, а другой его не отослал, и наоборот, если один процесс отсылает сообщение, а другой не собирается его получать. Здесь есть две возможности. Как операция посылки сообщения, так операция приема могут быть блокирующими и неблокирующими. Для операции send это означает, что либо процесс-отправитель может блокироваться до тех пор, пока получатель не вызовет receive, либо выполнение процесса может продолжаться далее независимо от наличия получателя. Для операции receive подобная ситуация возникает, когда эта операция вызвана раньше, чем сообщение было послано – в этом случае она может либо блокироваться до получения сообщения, либо возвращать управление сразу же. В зависимости от целей использования механизма сообщений могут быть полезны различные комбинации этих условий: Блокирующий send и блокирующий receive – эта схема известна под названием «схемы рандеву». Она не требует буферизации сообщений и часто используется для синхронизации процессов Неблокирующий send и блокирующий receive – такая схема очень распространена в системах клиент/сервер: серверный процесс блокируется в ожидании очередного запроса для обработки, в то время как клиент, пославший запрос серверу, может продолжать выполняться, не ожидая окончания обработки своего запроса Также весьма распространена схема, когда обе операции являются неблокирующими – в этом случае оба процесса могут продолжать выполнение, не дожидаясь окончания коммуникации Важно понимать, что в случае, если send является неблокирующим, процесс- отправитель не может знать, получено ли его сообщение. В этом случае, если требуется организовать гарантированную доставку сообщений, необходимо, чтобы процессы обменивались сообщениями-подтверждениями. Проблема потери сообщений встает также, если используется блокирующий receive – в этом случае процесс-получатель может оказаться заблокированным навечно. Поэтому в такую схему часто добавляется дополнительный примитив, позволяющий процессу-получателю проверить, есть ли для него сообщение, но не блокироваться, если его нет. Адресация. Другая важная проблема – организовать адресацию сообщений. Одно из решений – так называемая прямая адресация, при которой каждому из процессов присваивается некоторый идентификатор, и сообщения адресуются этим идентификаторам. При этом процесс-получатель может указать явно идентификатор отправителя, от которого он желает получить сообщение, либо получать сообщения от любого отправителя. Иное решение заключается в том, чтобы предоставить специальную структуру данных – почтовый ящик, или очередь сообщений, которая по сути своей является буфером, рассчитанным на определенное количество сообщений. В этом случае сообщения адресуются не процессам, а почтовым ящикам, при этом один и тот же ящик может использоваться и несколькими отправителями, и несколькими получателями. Такая схема, называемая косвенной адресацией, обеспечивает дополнительную гибкость. Заметим, что связь между процессом-получателем или отправителем и почтовым ящиком может быть не только статической (т.е. раз навсегда заданной при создании ящика), но и динамической; в последнем случае для установления и разрыва связи используются дополнительные примитивы (connect/disconnect). Кроме того, поскольку почтовый ящик является самостоятельным объектом, необходимо наличие примитивов создания и удаления ящика (create/destroy). Длина сообщения. Немаловажным аспектом является формат сообщений. В той или иной системе могут допускаться как сообщения фиксированной длины, так и переменной. В последнем случае в заголовке сообщения, помимо отправителя и получателя, должна указываться длина сообщения. Выбор того или иного варианта зависит от целей, которые преследует система обмена сообщениями, и от предполагаемой архитектуры ВС. Так, если предполагается возможность передачи больших объемов данных, то сообщения с переменной длиной будут более гибким решением и позволят сократить накладные расходы на большое количество коротких сообщений, где значительную часть занимает сам заголовок. С другой стороны, если обмен происходит между процессами на одной машине, немаловажную роль играет эффективность. Здесь, возможно, было бы уместно ограничить длину сообщения, с тем, чтобы использовать для их передачи системные буфера с быстрым доступом. В заключение отметим еще раз, что механизм обмена сообщениями является мощным и гибким средством синхронизации, пригодным для использования как на однопроцессорных системах и системах с общей памятью, так и в распределенных ВС. Однако, по сравнению с семафорами и мониторами, он, как правило, является менее быстрым. БИЛЕТ 27 Классические задачи синхронизации процессов. «Обедающие философы» Рассмотрим одну из классических задач, демонстрирующих проблему разделения доступа к критическим ресурсам – «задачу об обедающих философах» [2]. Данная задача иллюстрирует ситуацию, когда процессы конкурируют за право исключительного доступа к ограниченному числу ресурсов. Пять философов собираются за круглым столом, перед каждым из них стоит блюдо со спагетти, и между каждыми двумя соседями лежит вилка. Каждый из философов некоторое время размышляет, затем берет две вилки (одну в правую руку, другую в левую) и ест спагетти, затем кладет вилки обратно на стол и опять размышляет и так далее. Каждый из них ведет себя независимо от других, однако вилок запасено ровно столько, сколько философов, хотя для еды каждому из них нужно две. Таким образом, философы должны совместно использовать имеющиеся у них вилки (ресурсы). Задача состоит в том, чтобы найти алгоритм, который позволит философам организовать доступ к вилкам таким образом, чтобы каждый имел возможность насытиться, и никто не умер с голоду. Рассмотрим простейшее решение, использующее семафоры. Когда один из философов хочет есть, он берет вилку слева от себя, если она в наличии, а затем - вилку справа от себя. Закончив есть, он возвращает обе вилки на свои места. Данный алгоритм может быть представлен следующим способом: #define N 5 /* число философов*/ void philosopher (int i) /* i – номер философа от 0 до 4*/ { while (TRUE) { think(); /*философ думает*/ take_fork(i); /*берет левую вилку*/ take_fork((i+1)%N); /*берет правую вилку*/ eat(); /*ест*/ put_fork(i); /*кладет обратно левую вилку*/ put_fork((i+1)%N); /* кладет обратно правую вилку */ } } Функция take_fork() описывает поведение философа по захвату вилки: он ждет, пока указанная вилка не освободится, и забирает ее. На первый взгляд, все просто, однако, данное решение может привести к тупиковой ситуации. Что произойдет, если все философы захотят есть в одно и то же время? Каждый из них получит доступ к своей левой вилке и будет находиться в состоянии ожидания второй вилки до бесконечности. Другим решением может быть алгоритм, который обеспечивает доступ к вилкам только четырем из пяти философов. Тогда всегда среди четырех философов по крайней мере один будет иметь доступ к двум вилкам. Данное решение не имеет тупиковой ситуации. Алгоритм решения может быть представлен следующим образом: # define N 5 # define LEFT (i-1)%N /* номер легого соседа для i-ого философа */ # define RIGHT (i+1)%N /* номер правого соседа для i-ого философа*/ # define THINKING 0 /* философ думает */ # define HUNGRY 1 /* философ голоден */ # define EATING 2 /* философ ест */ typedef int semaphore; /* тип данных «семафор» */ int state[N]; /* массив состояний философов */ semaphore mutex=1; /* семафор для критической секции */ semaphore s[N]; /* по одному семафору на философа */ void philosopher (int i) /* i : номер философа от 0 до N-1 */ { while (TRUE) /* бесконечный цикл */ { think(); /* философ думает */ take_forks(i); /*философ берет обе вилки или блокируется */ eat(); /* философ ест */ put_forks(i); /* философ освобожает обе вилки */ } } void take_forks(int i) /* i : номер философа от 0 до N-1 */ { down(&mutex); /* вход в критическую секцию */ state[i] = HUNGRY; /*записываем, что i-ый философ голоден */ test(i); /* попытка взять обе вилки */ up(&mutex); /* выход из критической секции */ down(&s[i]); /* блокируемся, если вилок нет */ } void put_forks(i) /* i : номер философа от 0 до N-1 */ { down(&mutex); /* вход в критическую секцию */ state[i] = THINKING; /* философ закончил есть */ test(LEFT); /* проверить может ли левый сосед сейчас есть */ test(RIGHT); /* проверить может ли правый сосед сейчас есть*/ up(&mutex); /* выход из критической секции */ } void test(i) /* i : номер философа от 0 до N-1 */ { if (state[i] == HUNGRY && state[LEFT] != EATING && state[RIGHT] != EATING) { state[i] = EATING; up (&s[i]); } } БИЛЕТ 28 Задача «читателей и писателей» Другой классической задачей синхронизации доступа к ресурсам является задача «читателей и писателей» [2], иллюстрирующая широко распространенную модель совместного доступа к данным. Представьте себе ситуацию, например, в системе резервирования билетов, когда множество конкурирующих процессов хотят читать и обновлять одни и те же данные. Несколько процессов могут читать данные одновременно, но когда один процесс начинает записывать данные (обновлять базу данных проданных билетов), ни один другой процесс не должен иметь доступ к данным, даже для чтения. Возникает вопрос, как спланировать работу такой системы? Одно из решений представлено ниже: typedef int semaphore; /* тип данных «семафор» */ semaphore mutex = 1; /* контроль за доступом к «rc» (разделямый ресурс) */ semaphore db = 1; /* контроль за доступом к базе данных */ int rc = 0; /* кол-во процессов читающих или пишущих */ void reader (void) { while (TRUE) /* бесконечный цикл */ { down(&mutex); /* получить эксклюзивный доступ к «rc»*/ rc = rc + 1; /* еще одним читателем больше */ if (rc == 1) down(&db); /* если это первый читатель, нужно заблокировать эксклюзивный доступ к базе */ up(&mutex); /*освободить ресурс rc */ read_data_base(); /* доступ к данным */ down(&mutex); /*получить эксклюзивный доступ к «rc»*/ rc = rc - 1: /* теперь одним читателем меньше */ if (rc == 0) up(&db); /*если это был последний читатель, разблокировать эксклюзивный доступ к базе данных */ up(&mutex); /*освободить разделяемый ресурс rc */ use_data_read(); /* некритическая секция */ } } void writer (void) { while(TRUE) /* бесконечный цикл */ { think_up_data(); /* некритическая секция */ down(&db); /* получить эксклюзивный доступ к данным*/ write_data_base(); /* записать данные */ up(&db); /* отдать эксклюзивный доступ */ } } В этом примере, первый процесс, обратившийся к базе данных по чтению, осуществляет операцию |