Если пользователь применяет только один буфер передачи (а это типовой
случай), то возникает потребность только в одной "буферной"
подпрограмме pvm_initsend(). Она вызывается для упаковки
нового сообщения в буфер. Подпрограмма
pvm_initsend
очищает буфер передачи и пересоздает его для упаковки нового сообщения.
Схема кодирования, используемая при упаковке, устанавливается с помощью
encoding. Новый идентификатор буфера возвращается в bufid.
Опция encoding может иметь следующие значения:
PvmDataDefault.
По умолчанию используется XDR-кодирование - по той
причине, что ПВМ не может знать, собирается ли пользователь добавить
гетерогенную машину перед отправкой некоторого сообщения. Если пользователь
знает о том, что очередное сообщение будет послано машине, которая
понимает оригинальный формат, то он может воспользоваться кодированием
PvmDataRaw и сэкономить вычислительные затраты.
PvmDataRaw.
Не выполняется никакого кодирования. Сообщения посылаются
в своем исходном формате. Если принимающий процесс не сможет прочитать
данный формат, он вернет ошибку в процессе распаковки.
PvmDataInPlace.
Данные остаются на своем месте с целью уменьшения
затрат на кодирование. Буфер содержит только размеры элементов для
передачи и указатели на них. Когда pvm_send() вызывается,
элементы копируются прямо из пользовательской памяти. Данная опция
позволяет снизить число копирований сообщения, а значит и затраты,
в соответствие требованию пользователя не модифицировать элементы
в интервале между моментом упаковки и моментом передачи. Дополнительным
применением опции может быть: вызов одноразовой упаковки-модификации
и последующая многократная передача определенных элементов (или массивов)
по ходу работы приложения. Примеров может быть передача пограничных
регионов в дискретной реализации PDE.
Следующие подпрограммы работы с буферами сообщений нужно только в
тех ситуациях, когда пользователь желает на уровне приложения управлять
несколькими буферами сообщений. Большое количество буферов сообщений
вовсе не требуется для большинства случаев обмена сообщениями между
процессами. В ПВМ версии 3, в любой текущий момент времени, для каждого
процесса существуют только один "активный" буфер передачи и
только один "активный" буфер приема. Разработчик может создать
произвольное число буферов сообщений и переключаться между ними с
целью упаковки и передачи данных. Подпрограммы упаковки, передачи,
приема и распаковки затрагивают только "активные" буферы.
int bufid = pvm_mkbuf( int encoding)
call pvmfmkbuf( encodingб bufid)
Подпрограммой pvm_mkbuf создается новый пустой буфер передачи
и указывается кодировочный метод для упаковки сообщений. Она возвращает
идентификатор буфера bufid.
int info = pvm_freebuf( int bufid)
call pvmffreebuf(bufidб info)
Подпрограммой pvm_freebuf() возвращается в свободное пользование
буфер с идентификатором bufid. Это должно делаться после
того, как сообщение уже послано и больше не нужно. Если требуется,
вызывайте pvm_mkbuf(), чтобы вновь создать буфер для нового
сообщения. Ни один из данных запросов не нужен, если применяется pvm_initsend(),
реализует эти функции за пользователя.
Этими подпрограммами буфер с bufid устанавливается активным
буфером передачи (или приема); состояние предыдущего активного буфера
сохраняется, а его идентификатор возвращается в oldbuf.
Если при pvm_setsbuf() pvm_setrbuf() bufid
установлен в 0, то имеющийся буфер сохраняется, но нового буфера не
устанавливается. Такая возможность может быть использована для сохранения
текущего состояния сообщений приложения - чтобы математическая библиотека
или подсистема графического интерфейса, которые так же используют
сообщения ПВМ, не повредили содержимое буферов приложения. После того,
как прочие подсистемы отработали, буферы сообщения могут быть вновь
активированы.
Сообщения можно передать и без их перепаковки применением подпрограмм,
работающих с буферами сообщений. Это иллюстрируется следующим фрагментом:
Знаете ли Вы, что оптимальнй план - это план, доставляющий максимум целевой функции, отражающей выбранный критерий эффективности функционирования объекта планирования при соблюдении требований, заданных в форме системы уравнений и неравенств. Оптимальный план не обязательно является наилучшим планом, подлежащим утверждению и последующему выполнению, поскольку учитывает только те условия хозяйственной деятельности, которые удалось описать в математической форме. Во многих случаях процесс планирования требует использования информации, содержащейся во множестве разнообразных оптимальных планов.
