Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

04 ос взаимодействие_процессов_1

425 views

Published on

  • Be the first to comment

  • Be the first to like this

04 ос взаимодействие_процессов_1

  1. 1. Операционные Системы Взаимодействие процессов КРСУ, Бишкек, Гайдамако В.В.
  2. 2. Необходимость синхронизацииВ любой момент времени в ядре могут бытьактивны несколько процессов (ядрореентерабельно), использующих одни и те жеструктуры ядраИзначально система невытесняющая, процессдобровольно покидает процессор, всегдаоставляя ядро в корректном состоянии(современные системы в случае реальноговремени используют вытеснение) КРСУ, Бишкек, Гайдамако В.В.
  3. 3. Пример отстутствия синхронизацииКРСУ. ОперационныеСистемы. Процессы.Гайдамако В.В.
  4. 4. Эффект гонок – Race ConditionРезультат выполненияпоследовательности действийзависит не только от алгоритма ивходных данных КРСУ, Бишкек, Гайдамако В.В.
  5. 5. Критическая секцияУчасток кода программы, привыполнении которого можетвозникнуть эффект гонок КРСУ, Бишкек, Гайдамако В.В.
  6. 6. Синхронизация необходима при многопроцессорной обработке при операции блокировки при прерыванияхКРСУ. ОперационныеСистемы. Процессы.Гайдамако В.В.
  7. 7. КРСУ. ОперационныеСистемы. Процессы.Гайдамако В.В.
  8. 8. КРСУ, Бишкек, Гайдамако В.В.
  9. 9. КРСУ, Бишкек, Гайдамако В.В.
  10. 10. Напоминание: требования к алгоритмам Задача должна быть решена чисто программным способом на обычной машине, неимеющей специальных команд взаимоисключения. При этом предполагается, чтоосновные инструкции языка программирования (такие примитивные инструкции какload, store, test) являются атомарными операциями. Не должно существовать никаких предположений об относительных скоростяхвыполняющихся процессов или числе процессоров, на которых они исполняются. Если процесс Pi исполняется в своем критическом участке, то не существуетникаких других процессов, которые исполняются в своих соответствующихкритических секциях. Это условие получило название условия взаимоисключения(mutual exclusion). Процессы, которые находятся вне своих критических участков и не собираютсявходить в них, не могут препятствовать другим процессам входить в их собственныекритические участки. Если нет процессов в критических секциях, и имеютсяпроцессы, желающие войти в них, то только те процессы, которые не исполняются вremainder section, должны принимать решение о том, какой процесс войдет в своюкритическую секцию. Такое решение не должно приниматься бесконечно долго. Этоусловие получило название условия прогресса (progress). Не должно возникать бесконечного ожидания для входа процесса в свойкритический участок. От того момента, когда процесс запросил разрешение на входв критическую секцию, и до того момента, когда он это разрешение получил, другиепроцессы могут пройти через свои критические участки лишь ограниченное числораз. Это условие получило название условия ограниченного ожидания (boundwaiting).Надо заметить, что описание соответствующего алгоритма в нашем случае означает описаниеспособа организации пролога и эпилога для критической секции. КРСУ, Бишкек, Гайдамако В.В.
  11. 11. Напоминание: алгоритмы с buisy waitЗапрет прерыванийПеременная-замок (lock variable)Строгое чередование (strictalteration)Флаги готовностиАлгоритм ПетерсонаАлгоритм булочной (BakeryAlgorithm) КРСУ, Бишкек, Гайдамако В.В.
  12. 12. Планирование процессов Планировщик – часть ядра, распределяющая процессорное время между процессами Долгосрочное и краткосрочное планирование – выбор алгоритма и «кто следующий»КРСУ. ОперационныеСистемы. Процессы.Гайдамако В.В.
  13. 13. Аппаратная поддержка. Test- and-Set  Test-and-Set (Проверить и присвоить )О выполнении команды Test-and-Set, осуществляющей проверку значения логической переменной с одновременной установкой ее значения в 1, можно думать, как о выполнении функции int Test_and_Set (int *target){ int tmp = *target; *target = 1; return tmp; }С использованием этой атомарной команды мы можем модифицировать наш алгоритм для переменной-замка, так чтобы он обеспечивал взаимоисключения shared int lock = 0; while (some condition) { while(Test_and_Set(&lock)); critical section lock = 0; remainder section }К сожалению, даже в таком виде полученный алгоритм не удовлетворяет условию ограниченного ожидания для алгоритмов. Подумайте, как нужно его изменить для соблюдения всех условий. КРСУ, Бишкек, Гайдамако В.В.
  14. 14. Аппаратная поддержка. Swap void Swap (int *a, int *b){ int tmp = *a; *a = *b; *b = tmp; } Применяя атомарную команду Swap, мы можем реализовать предыдущий алгоритм, введя дополнительную логическую переменную key локальную для каждого процесса: shared int lock = 0; int key; while (some condition) { key = 1; do Swap(&lock,&key); while (key); critical section lock = 0; remainder section } КРСУ, Бишкек, Гайдамако В.В.
  15. 15. Резюме1. Рассмотренные методы громоздки и неэлегантны2. Процедура ожидания входа в критический участок включает в себя достаточно длительное вращение процесса в пустом цикле, вхолостую пожирая драгоценное время процессора.3. Инверсия приоритетов КРСУ, Бишкек, Гайдамако В.В.
  16. 16. Механизмы синхронизации более высокого уровня:семафоры,мониторы исообщения КРСУ, Бишкек, Гайдамако В.В.
  17. 17. СемафорыДейкстра (Dijkstra) в 1965 годуP(S):пока S == 0 процессблокируется;S = S – 1;V(S):S = S + 1; КРСУ, Бишкек, Гайдамако В.В.
  18. 18. Решение проблемы producer- consumer с помощью семафоровSemaphore mutex = 1; Semaphore empty = N, где N – Semaphore mutex = 1; емкость буфера; Semaphore empty = N, где N Semaphore full = 0; – емкость буфера; Semaphore full = 0;Producer:while(1) { Consumer:produce_item; while(1) { P(empty); P(mutex); P(full); put_item; P(mutex); V(mutex); V(full); put_item; V(mutex); V(empty);} consume_item; }} КРСУ, Бишкек, Гайдамако В.В.
  19. 19. ПроблемаДопустим, что в рассмотренном примере мыслучайно поменяли местами операции P,сначала выполняя ее для семафора mutex, ауже затем для семафоров full и empty.Допустим теперь, что потребитель, войдя всвой критический участок (mutex сброшен),обнаруживает, что буфер пуст. Он блокируетсяи начинает ждать появления сообщений. Нопроизводитель не может войти в критическийучасток, для передачи информации, так как тотзаблокирован потребителем. Получаемтупиковую ситуацию. КРСУ, Бишкек, Гайдамако В.В.
  20. 20. Мониторы1974 году Хор(Hoare) Мониторы представляют собой тип данных, который может быть с успехом внедрен в объектно-ориентированные языки программирования. Монитор обладает своими собственными переменными, определяющими его состояние. Значения этих переменных извне монитора могут быть изменены только с помощью вызова функций-методов, принадлежащих монитору. В свою очередь, эти функции-методы могут использовать в своей работе только данные, находящиеся внутри монитора и свои параметры. На абстрактном уровне можно описать структуру монитора следующим образом:monitor monitor_name {описание переменных ; void m1(...){... } void m2(...){... } ... void mn(...){... } { КРСУ, Бишкек, Гайдамако В.В.блок инициализации внутрениих переменных ;
  21. 21. Мониторы, продолжениеВажной особенностью мониторов является то, что влюбой момент времени только один процесс может бытьактивен, т. е. находиться всостоянии готовность или исполнение, внутри данногомонитора. Поскольку мониторы представляют собойособые конструкции языка программирования, токомпилятор может отличить вызов функции,принадлежащей монитору, от вызовов других функций иобработать его специальным образом, добавив к немупролог и эпилог, реализующий взаимоисключение. Таккак обязанность конструирования механизмавзаимоисключений возложена на компилятор, а не напрограммиста, работа программиста при использованиимониторов существенно упрощается, а вероятностьпоявления ошибок становится меньше. КРСУ, Бишкек, Гайдамако В.В.
  22. 22. Мониторы, waitОднако одних только взаимоисключений не достаточнодля того, чтобы в полном объеме реализовать решениезадач, возникающих при взаимодействии процессов.Нам нужны еще и средства организации очередностипроцессов, подобно семафорам full и empty впредыдущем примере. Для этого в мониторах быловведено понятие условных переменных (conditionvariables), над которыми можно совершать двеоперации wait и signal, до некоторой степени похожиена операции P и V над семафорами.Если функция монитора не может выполняться дальше,пока не наступит некоторое событие, она выполняетоперацию wait над какой-либо условной переменной.При этом процесс, выполнивший операцию wait,блокируется, становится неактивным, и другой процессполучает возможность войти в монитор. КРСУ, Бишкек, Гайдамако В.В.
  23. 23. Мониторы, signalКогда ожидаемое событие происходит, другой процессвнутри функции-метода совершает операцию signal надтой же самой условной переменной. Это приводит кпробуждению ранее заблокированного процесса, и онстановится активным. Если несколько процессовдожидались операции signal для этой переменной, тоактивным становится только один из них. Что нам нужнопредпринять для того, чтобы у нас не оказалось двухпроцессов, разбудившего и пробужденного,одновременно активных внутри монитора? Хорпредложил, чтобы пробужденный процесс подавлялисполнение разбудившего процесса, пока он сам непокинет монитор. Несколько позже Хансен(Hansen) предложил другой механизм: разбудившийпроцесс покидает монитор немедленно послеисполнения операции signal. Мы будем придерживатьсяподхода Хансена. КРСУ, Бишкек, Гайдамако В.В.
  24. 24. Producer-consumer, мониторmonitor ProducerConsumer { condition full, empty; int count; void put() { if(count == N) full.wait; put_item; count += 1; if(count == 1) empty.signal; } void get() { if (count == 0) empty.wait; get_item(); count -= 1; if(count == N-1) full.signal; } { count = 0; }} КРСУ, Бишкек, Гайдамако В.В.
  25. 25. Producer-consumer, producerProducer:  while(1) {    produce_item;  ProducerConsumer.put(); }  КРСУ, Бишкек, Гайдамако В.В.
  26. 26. Producer-consumer, consumerConsumer:  while(1) {  ProducerConsumer.get();  consume_item;  }  КРСУ, Бишкек, Гайдамако В.В.
  27. 27. Реализация мониторовРеализация мониторов требует разработкиспециальных языков программирования икомпиляторов для них. Мониторы встречаютсяв таких языках как параллельный Евклид,параллельный Паскаль, Java и т.д. Эмуляциямониторов с помощью системных вызовов дляобычных широко используемых языковпрограммирования не так проста, как эмуляциясемафоров. Поэтому можно пользоваться ещеодним механизмом со скрытымивзаимоисключеньями, механизмом, о котороммы уже упоминали, — передачей сообщений. КРСУ, Бишкек, Гайдамако В.В.
  28. 28. Сообщения. Примитивы send- receiveПрямая адресация:send(P, message)—послать сообщениеmessage процессу P;receive(Q, message) — получить сообщениеmessage от процесса Q.Косвенная адресация:send(A, message) — послать сообщениеmessage в почтовый ящик A;receive(A, message) — получить сообщениеmessage из почтового ящика A. КРСУ, Бишкек, Гайдамако В.В.
  29. 29. Сообщения - синхронизацияПримитивы send и receive уже имеют скрытыйот наших глаз механизм взаимоисключения.Более того, в большинстве систем они ужеимеют и скрытый механизм блокировки причтении из пустого буфера и при записи вполностью заполненный буфер. Реализациярешения задачи producer-consumer для такихпримитивов становится неприличнотривиальной. Надо отметить, что, несмотря напростоту использования, передача сообщенийв пределах одного компьютера происходитсущественно медленнее, чем работа ссемафорами и мониторами. КРСУ, Бишкек, Гайдамако В.В.
  30. 30. Эквивалентность семафоров, мониторов и сообщенийРеализация мониторов и передачи сообщений с помощью семафоровРеализация семафоров и передачи сообщений с помощью мониторовРеализация семафоров и мониторов с помощью очередей сообщений КРСУ, Бишкек, Гайдамако В.В.

×