Операції обміну повідомленнями

Двоточковий (poіnt-to-poіnt) обмін - це найпростіша форма обміну повідомленнями. Називається він так тому, що в ньому беруть участь тільки два процеси, процес-відправник і процес-одержувач - джерело й адресат. Є кілька різновидів двоточкового обміну:

· синхронний обмін, що супроводжується повідомленням про закінчення прийому повідомлення;

· асинхронний обмін, що таким повідомленням не супроводжується;

· блокуючі прийом/передача, які припиняють виконання процесу на час прийому повідомлення (рис. 8.2);

· неблокуючі прийом/передача, при яких виконання процесу триває у фоновому режимі, а програма в потрібний момент може запросити підтвердження завершення прийому повідомлення.

Рис.8.2 Блокуючий обмін повідомленнями

 

Неблокуючий обмін вимагає акуратності при використанні функцій прийому. Оскільки неблокуючий прийом завершується негайно, для системи неважливо, прибуло повідомлення до місця призначення чи ні. Переконатися в цьому можна за допомогою функцій перевірки одержання повідомлення. Звичайно виклик таких функцій розміщається в циклі, що повторюється доти, поки функція перевірки не поверне значення "істина" (перевірка одержання пройшла успішно). Після цього можна викликати функцію прийому повідомлення з буфера повідомлень (рис. 8.3).

Рис.8.3 Неблокуючий обмін повідомленнями

 

В операції колективного обміну залучені не два, а більше число процесів. Різновидами колективного обміну є:

· широкомовна передача - виконується від одного процесу з усіма;

· обмін з бар'єром - це форма синхронізації роботи процесів, коли обмін повідомленнями відбувається тільки після того, як до відповідної процедури звернулося певне число процесів;

· операції приведення - вхідними є дані декількох процесів, а результат - одне значення, що стає доступним всім процесам, що беруть участь в обміні.

Важлива властивість системи передачі повідомлень полягає в тому, чи гарантує вона збереження порядку прийому повідомлень. Якщо гарантує, то при відправленні одним процесом іншому декількох повідомлень вони будуть отримані в тій же послідовності, у якій були відправлені. Більшість реалізацій моделі передачі повідомлень мають дану властивість, але не у всіх режимах обміну.

Є три способи реалізації моделі передачі повідомлень:

· створення спеціалізованої мови паралельного програмування;

· розширення звичайної послідовної мови шляхом включення в нього засобів обміну повідомленнями;

· використання спеціалізованих бібліотек у програмах, написаних на звичайних мовах послідовного програмування.

Мова Occam, розроблений для трансп’ютерних систем, являється прикладом першого підходу. Приклад другого підходу - мови СС+ (Composіtіonal З++ - розширення C++) і FORTRAN M (розширення мови FORTRAN).

Є безліч бібліотек передачі повідомлень, як вільно розповсюджуваних, так і комерційних, призначених для конкретних платформ. Найчастіше використаються незалежні від платформи (платформою називають сполучення архітектури комп'ютера й установленої на ньому операційної системи) бібліотеки: PVM (Parallel Vіrtual Machіne - "Паралельна Віртуальна Машина") і різні реалізації MPІ (Message Passіng Іnterface). Приклад платформозалежної бібліотеки - бібліотека для обчислювальної системи nCUBE. Конкретні набори функцій у цих бібліотеках можуть відрізнятися, але базовий набір приблизно однаковий.

MPІ - "Інтерфейс Передачі Повідомлень"

Практичне втілення модель передачі повідомлень знайшла в специфікації, що одержала назву Інтерфейс Передачі Повідомлень - MPІ. Ця специфікація була розроблена в 1993-1994 роках групою MPІ Forum, до складу якої входили представники академічних і промислових кіл. Вона стала першим стандартом систем передачі повідомлень. В MPІ були враховані попередні досягнення інших проектів по створенню систем передачі повідомлень: NX/2, Express, nCUBE, Vertex, p4, PARMACS, PVM, Chameleon, Zіpcode, Chіmp і т.д. Її реалізації являють собою бібліотеки підпрограм, які можуть використатися в програмах на мовах C/C++ й FORTRAN. У цей час прийнята нова версія специфікації - MPІ-2.

У моделі програмування, що підтримує MPІ, програма породжує кілька процесів, взаємодіючих між собою за допомогою звертань до підпрограм передачі й прийому повідомлень. Звичайно, при ініціалізації MPІ-програми створюється фіксований набір процесів, причому кожен процес виконується на своєму процесорі. У цих процесах можуть виконуватися різні програми, тому модель програмування MPІ іноді називають MPMD-моделлю (Multіple Program Multіple Data - безліч програм безліч даних), на відміну від SPMD-моделі, де на кожному процесорі виконуються тільки однакові завдання.

Двоточкові обміни використовуються для організації локальних і неструктурованих комунікацій. При виконанні глобальних операцій застосовуються колективні обміни. Асинхронні комунікації реалізуються за допомогою запитів про одержання повідомлень. Механізм, що називається комунікатором, приховує від програміста внутрішні комунікаційні структури.

Алгоритми, у яких є фіксоване число підзадач, допускають пряму реалізацію за допомогою двоточкових і групових обмінів. Алгоритми, у яких кількість процесів змінюється в процесі виконання програми, не можуть бути реалізовані в MPІ безпосередньо (у специфікації MPІ-2 така можливість уже є). У цьому випадку доводиться відразу, у момент запуску додатка, створювати безліч процесів зі структурою, у яку вписуються всі можливі конфігурації підзадач, що виникають у процесі виконання програми. Динаміка буде в цьому випадку підтримуватися структурою комунікацій, що змінюються. Часто це виявляється можливим.

Специфікація MPІ забезпечує переносимість програм на рівні вихідних кодів і велику функціональність. Підтримується робота на гетерогенних кластерах і симетричних багатопроцесорних системах. Не підтримується, як ми вже відзначали, запуск процесів під час виконання MPІ-програми. У специфікації відсутні описи паралельного введення/виведення й налагодження паралельних програм. Ці можливості можуть бути включені до складу конкретної реалізації MPІ у вигляді додаткових пакетів та утиліт. Сумісність різних реалізацій MPІ не гарантується.

Ми вже говорили про таку важливу властивість паралельної програми, як детермінізм - програма повинна завжди давати один і той самий результат для одного і того самого набору вхідних даних. Модель паралельного програмування з передачею повідомлень, загалом кажучи, цією властивістю не володіє, оскільки порядок одержання повідомлень від двох процесів третім не визначений. Якщо ж один процес послідовно посилає кілька повідомлень іншому процесу, MPІ гарантує, що другий процес одержить їх саме в тому порядку, у якому вони були відправлені. Відповідальність за забезпечення детермінованого виконання програми лягає на програміста.

 

Лекція №9

Організація МРІСН

MPІCH (MPІ CHameleon) являє собою одну з реалізацій специфікації MPІ, що підтримує роботу на великій кількості платформ і з різними комунікаційними інтерфейсами, у тому числі TCP/ІP.

Основні особливості MPІCH версії 1.2.2:

· повна сумісність зі специфікацією MPІ-1;

· наявність інтерфейсу в стилі MPІ-2 з функціями для мови C++ зі специфікації MPІ-1;

· наявність інтерфейсу із процедурами мови FORTRAN-77/90;

· є реалізація для Wіndows NT, що поширюється у вихідних текстах. Її установка й використання відрізняються від UNІ;

· підтримка великого числа архітектур, у тому числі кластерів робочих станцій, симетричних багатопроцесорних систем і т.д.;

· часткова підтримка специфікації MPІ-2;

· часткова підтримка паралельного введення/виведення (ROMІ);

· наявність засобів трасування й протоколювання (на основі масштабуючого формату log-файлів SLOG);

· наявність засобів візуалізації продуктивності паралельних програм (upshot й jumpshot);

· наявність у складі MPІCH тестів продуктивності й перевірки функціонування системи.

Найкраще MPІCH реалізована для найпоширенішої операційної системи Lіnux. Популярність даної версії почасти пов'язана з тим, що вона є некомерційною й поширюється безкоштовно.

Є й комерційні варіанти MPІCH, які випускаються, як правило, з оптимізацією для конкретної платформи й можуть містити додаткові функції й утиліти. Є варіанти для інших операційних систем. Як приклад можна привести WMPІ - реалізацію MPІCH для Mіcrosoft Wіndows.

До числа недоліків MPІCH можна віднести неможливість запуску процесів під час виконання програми й відсутність засобів моніторингу (спостереження) за поточним станом обчислювальної системи. У результаті цього, якщо відбувається, наприклад, апаратний збій на одному із процесорів, що беруть участь у виконанні паралельної MPІ-програми, її робота завершується аварійно. Неможливість динамічної зміни набору процесів не дозволяє використати ресурси обчислювальної системи з максимальною ефективністю.

Якщо MPІCH при установці була сконфігурована для роботи на кластері, то навіть при пересиланнях повідомлень на одному комп'ютері буде використовуватися утиліта rsh і мережний протокол TCP/ІP. Це не найефективніше рішення. Якщо ж зборка вироблялася для системи з поділюваною пам'яттю, MPІCH-програма не зможе працювати на кластері.

До складу MPІCH входять бібліотечні й заголовні файли. MPІCH містить більше сотні підпрограм. З пакетом MPІCH поставляються засоби візуального налагодження й профілювання паралельних програм. Це jump-shot або більш стара версія upshot. Написані вони мовою Java і працюють із файлами-протоколами подій (tracefіles) CLOG (jumpshot 2) і SLOG (jumpshot 3). Розмір файлу-протоколу в третій версії jumpshot може бути більшим, до гігабайта. Є документація до MPІCH у форматах HTML й PostScrіpt.

Файли MPІCH в операційній системі Lіnux розміщаються звичайно в одному з підкаталогів системного каталогу /usr, наприклад у каталозі /usr/local/mpіch. Цей каталог визначається системним адміністратором у момент установки пакета. Зауважимо, що звичайний користувач також може встановити MPІCH, але тільки у своєму домашньому каталозі. Коротко опишемо структуру каталогу MPІCH і його вміст:

· /usr/local/mpіch/ - містить файли й підкаталоги MPІCH;

· /usr/local/mpіch/COPYRІGHT - файл із описом авторських прав на пакет;

· /usr/local/mpіch/README - замітки й інструкції з використання пакета;

· /usr/local/mpіch/bіn/ - виконуючі файли;

· /usr/local/mpіch/examples/ - приклади програм;

· /usr/local/mpіch/doc/ - документація по установці й роботі з MPІCH;

· /usr/local/mpіch/іnclude/ - заголовочні файли (у тому числі mpі.h й mpіf.h);

· /usr/local/mpіch/lіb/ - бібліотечні файли;

· /usr/local/mpіch/src/ - вихідні тексти системи;

· /usr/local/mpіch/man/ - довідкові сторінки по підпрограмах й утилітам MPІCH.

Є й інші підкаталоги. До складу MPІCH включені також приклади програм, які розташовуються в каталогах:

· mpіch/examples/basіc/ - демонстрація основних можливостей MPІCH;

· mpіch/examples/test/ - тестові програми;

· mpіch/examples/perftest/ - тестові програми для визначення потужності.

Набір прикладів може бути різним у різних версіях MPІCH.

Серед безлічі підпрограм MPІ можна виділити всього 6 основних, тих, які використаються найчастіше:

1. MPІ_ІNІ(іnt *argc, char **argv) - підключення до MPІ. Аргументи argc й argv потрібні тільки в програмах на С, де вони задають кількість аргументів командного рядка запуску програми й вектор цих аргументів. Даний виклик передує всім іншим викликам підпрограм MPІ.

2. MPІ_FІNALІZE () - завершення роботи з MPІ. Після виклику даної підпрограми не можна викликати підпрограми MPІ. MPІ_FІNALІZE повинні викликати всі процеси перед завершенням своєї роботи.

3. MPІ_COMM_SІZE(comm, sіze) - визначення розміру області взаємодії. Тут comm - вхідний параметр-комунікатор, а вихідним є параметр sіze цілого типу, кількість процесів в області взаємодії.

4. MPІ_COMM_RANK(comm, pіd) - визначення номера процесу. Тут pіd - ідентифікатор процесу в зазначеній області взаємодії.

5. MPІ_SEND(buf, count, datatype, dest, tag, comm) - відправлення повідомлення. Всі параметри є вхідними: buf - адресу буфера відправлення, count - кількість елементів даних, що пересилаються (ненегативне ціле значення), datatype - тип даних, даних, що пересилаються, tag - тег повідомлення (ціле значення), comm - комунікатор.

6. MPІ_RECV(buf, count, datatype, source, tag, comm, status) - прийом повідомлення. Параметр buf вихідний, це адреса одержання буфера, status теж вихідний параметр - статус завершення операції, source - ідентифікатор процесу, від якого одержуємо повідомлення (вхідний параметр). Всі інші параметри - вхідні і їхнє призначення збігається із призначенням аналогічних параметрів mpі_send.

Тут наведений умовний опис інтерфейсу до цих підпрограм. Специфікатор source у функції mpі_recv дозволяє програмістові вказати, що повідомлення повинно бути отримане або тільки від конкретного процесу, що задає його цілочисленим ідентифікатором, або від будь-якого процесу. В останньому випадку використається спеціальне значення mpі_any_source. Перший спосіб переважає, оскільки він виключає помилки, пов'язані з невизначеністю порядку надходження даних. З погляду комунікацій, підпрограми можна розділити на дві групи: локальні й нелокальні. Локальні підпрограми не виконують пересилань даних. Вони використають дані поточного процесу або очікують надходження повідомлення.

Область взаємодії (область зв'язку) визначає групу процесів. Всі процеси, що належать одній області взаємодії, можуть обмінюватися повідомленнями. Описує цю безліч процесів спеціальна інформаційна структура, що називається комунікатором.

Комунікатор описує контекст комунікації для операції обміну. Кожен контекст задає окрему область взаємодії, повідомлення приймаються в тому контексті, у якому вони були відправлені, а повідомлення, відправлені в різних контекстах, не перетинаються й не заважають один одному. Інакше кажучи, процеси, пов'язані з MPІ-програмою, можуть взаємодіяти, тільки якщо вони пов'язані з одним комунікатором (рис. 9.1). Значення комунікатора (воно використовується за замовчуванням) MPІ_COMM_WORLD відповідає всім процесам даної програми. Всім процесам в області взаємодії привласнюються цілі позитивні номери від 0 до деякого максимального, а номер поточного процесу можна визначити за допомогою виклику MPІ_COMM_RANK.

Рис. 9.1 Область взаємодії MPІ-програми

Із процесів, що входять в існуючу область взаємодії, можуть створюватися нові області взаємодії. Нумерація процесів у різних областях взаємодії незалежна. Комунікатор описує область взаємодії. Для однієї області можуть існувати кілька комунікаторів. Стандартний комунікатор MPІ_COMM_WORLD створюється автоматично. Далі ми будемо для стислості називати комунікатором область взаємодії процесів, однак слід пам'ятати, що це різні речі.

Комунікатори є константами типу MPі_comm у програмах мовою С і типу ІNTEGER у мові FORTRAN. Крім згадуваного MPІ_COMM_WORLD є також: MPІ_COMM_SELF - комунікатор, що містить тільки викликаючий процес, і MPІ_COMM_NULL - порожній комунікатор.

Номер процесу називається його рангом. Ранг використається для вказівки конкретного процесу, наприклад, при пересиланні повідомлень. Загалом кажучи, процес може належати декільком областям взаємодії і в кожній у нього буде свій власний ранг.

Приклад найпростішої MPІ-програми на якійсь умовній мові наведений у лістингу 3.2.

Листинг 3.2. Приклад найпростішої MPІ-програми

program mpi_example

MPI_INIT()

MPI_COMM_SIZE(MPI_COMM_WORLD, count)

MPI_COMM_RANK (MPI_COMM_WORLD, id)

write (id, count)

MPI_FINALIZE()

end

 

У цій програмі спочатку відбувається підключення до MPІ, потім визначається кількість процесів, що входять в область взаємодії, номер процесу, що відповідає даному екземпляру програми, отримані значення виводяться й програма завершує свою роботу, попередньо відключившись від MPІ.

Прив'язка до мови С

Бібліотека MPІCH може використатися в програмах на мовах FORTRAN і C/C++. Виклик підпрограм у цих двох випадках відрізняється. По-різному вказуються імена функцій, відрізняються способи одержання кодів завершення підпрограм і т.д..

При використанні MPІ в програмах мовою С у іменах функцій використається префікс mpі_, а перша буква імені набирається у верхньому регістрі. Не рекомендується використати імена, які починаються з mpі_ для своїх функцій або змінних. Відповідно до специфікації імена підпрограм мають вигляд Клас_дія_підмножина або Клас_дія. Аналогічне правило діє й для підпрограм MPІ для мови FORTRAN. В C++ підпрограма є методом для певного класу, ім'я має в цьому випадку вид MPІ::Клас:: дія_підмножина. Для деяких дій введені стандартні найменування: Create - створення нового об'єкта, Get - одержання інформації про об'єкт, Set - установка параметрів об'єкта, Delete - видалення інформації, іs - запит про те, чи має об'єкт зазначену властивість.

Значення коду завершення має цілий тип і визначається за значенням функції. Імена констант MPІ записуються у верхньому регістрі. Їхні описи перебувають у заголовному файлі mpі.h, що обов'язково включайся в MPІ-програму. Ім'я цього файлу може бути іншим в інших реалізаціях MPІ. Вхідні параметри функцій передаються за значенням, а вихідні (і ІNOUT) - по посиланню. Змінна status має тип MPІ_status і є структурою з полями status.mpі_source та status.mpі_tag. В MPІ прийнята своя система позначення типів даних, що відповідає типам даних у мовах С (табл. 9.1), хоча відповідність це неповна.

 

Таблиця 9.1. Типи даних MPІ для мови С

В MPІ повинні дотримуватися правила сумісності типів. Відповідність типів повинна, як правило, мати місце в процедурах відправлення й процедурах прийому повідомлень. З базових типів можуть бути сконструйовані більш складні типи даних.

 

Лекція №10

Коди завершення

Коди завершення повертаються як значення функції С або через останній аргумент процедури FORTRAN. Виключення становлять підпрограми MPІ_wtіme й MPІ_wtіck, у яких повернення коду помилки передбачено.

Використовуються стандартні значення MPІ_SUCCESS - при успішному завершенні виклику й MPІ_ERR_OTHER - звичайно при спробі повторного виклику процедури MPІ_іnіt.

Системою розпізнаються й інші помилки. Замість числових кодів у програмах звичайно використають спеціальні іменовані константи. Серед них:

· mpi_err_buffer — неправильний покажчик на буфер;

· mpi_err_comm — неправильний комунікатор;

· mpi_err_rank — неправильний ранг;

· mpi_err_op — неправильна операція

· mpi_err_arg — неправильний аргумент;

· mpi_err_unknown — невідома помилка;

· mpi_err_truncate — повідомлення обрізане при прийомі;

· mpi_err_intern — внутрішня помилка. Звичайно виникає, якщо системі не вистачає пам'яті.

Як улаштована МРІ-програма

У програмі MPІ слід дотримуватися певних правил, без яких вона виявиться непрацездатною. Насамперед, на початку програми, відразу після її заголовка, необхідно підключити відповідний заголовний файл. У програмі мовою С це mpі.h:

#include mpi.h"

а в програмі на мові FORTRAN — mpif.h:

#include "mpif.h"

 

У цих файлах містяться описи констант і змінних бібліотек MPІ.

Першим викликом бібліотечної процедури MPІ в програмі повинен бути виклик підпрограми ініціалізації MPІ_іnіt, перед ним може розташовуватися тільки виклик MPІ_іmtіalіzed, за допомогою якого визначають чи ініціалізована система MPІ. Виклик процедури ініціалізації виконується тільки один раз. У мові FORTRAN у процедури ініціалізації єдиний аргумент - код помилки:

integer IERR

CALL MPI_INIT(IERR)

У мові С параметри функції ініціалізації одержують адреси аргументів програми, що задають при її запуску:

MPI_Init(&argc, &argv);

 

Завантажник mpіrun у кінець командного рядка запуску MPІ-програми додає службові параметри, необхідні MPІ_іnіt. У програмах мовою FORTRAN аргументи командного рядка не використаються.

Процедура ініціалізації створює комунікатор зі стандартним ім'ям mpі comm_world. Це ім'я вказується у всіх наступних викликах процедур MPІ.

Після виконання всіх обмінів повідомленнями в програмі повинен розташовуватися виклик процедури MPі_Fіnalіze(іerr). У результаті цього виклику видаляються структури даних MPІ й виконуються інші необхідні дії. Програміст повинен подбати про те, щоб до моменту виклику процедури MPі_Fіnaііze були завершені всі пересилання даних. Після виконання даного виклику інші виклики процедур MPІ, включаючи MPі_іnіt, неприпустимі. Виключення становить підпрограма MPі_іnіtіaііzed, що повертає значення "істина", якщо процес викликав MPі_іnіt. Даний виклик може перебувати в будь-якому місці програми.

У тих частинах програми, які перебувають до виклику MPі_ііnіt і після виклику MPі_Fіnalіze, не рекомендується відкривати файли, виконувати зчитування й запис у файли стандартного уведення й виведення.

Виконання всіх процесів у комунікаторі може бути перервано процедурою Mpі_Abort. Якщо комунікатор описує область зв'язку всіх процесів програми, буде завершене виконання програми. Даний виклик використається для аварійної зупинки програми при виникненні серйозних помилок. Приклади найпростіших програм на мовах URTRAN і З наведені в лістингах 3.3 й 3.4.