вторник, 4 сентября 2007 г.

Рандеву – концепция параллельного программирования

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

Коль скоро рандеву – это основная концепция организации межпроцессного взаимодействия в языке Ada, то в поисках ответ о том, что такое рандеву, я решил обратиться, что называется, к первоисточникам. В ru-нете есть сайт по языку Ada, где я обнаружил книгу, в которой излагается суть механизма рандеву и принципы его описания в языке. Книга называется «Адское программирование» и в «главе 15: Многозадачность» описывается идея рандеву. Процитирую ту часть, в которой описывается суть термина, а за подробностями и разъяснениями предлагаю обратиться к самой книге.

Как один из механизмов обеспечения надежного межзадачного обмена данными и взаимной синхронизации работы задач, Ада предоставляет механизм рандеву.
Основополагающая идея механизма рандеву достаточно проста. В спецификации задачи публикуются различные входы (entry) в задачу, в которых она готова ожидать обращения к ней от других задач. Далее, в теле задачи указываются инструкции принятия обращений к соответствующим входам, указанным в спецификации этой задачи.

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

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

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


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

В следующий раз расскажу о том, как я, пытаясь реализовать взаимодействие между потоками в ядре библиотеки act-o, естественным путем пришел к точно такой же идее взаимодействия как рандеву, еще до того, как познакомился с вышеизложенным материалом.
Оставайтесь на связи… :-)

воскресенье, 2 сентября 2007 г.

И все-таки она необходима

Стоило только мне вынести предыдущую заметку на один форум, как оказалось, что:
  1. Сборка мусора необходима не только в многопоточных программах, но и в компонентном программировании.
  2. Существует статья, в которой предпринята попытка доказать необходимость автоматического управления памятью в компонентных программах.
Конечно, это вопрос еще предстоит проработать более подробно применительно именно к многопоточному программированию, но думаю, что общий ответ явно не вызывает сомнения – автоматическое управление памятью (сборка мусора) необходимо в системах с массовым параллелизмом.