від його джерела, тега і комунікатора. тег дозволяє програмі розрізняти типи повідомлень. Джерело спрощує програмування. Замість того, щоб мати унікальний тег для кожного повідомлення, кожен процес, який посилає ту ж саму інформацію, може використовувати той же тег. Але навіщо потрібен комунікатор? p align="justify">
Приклад
Припустимо ви посилаєте повідомлення між вашими процесами, і, крім того, викликаєте ряд бібліотек, отриманих звідки-небудь, які також породжують процеси, що виконуються на різних вузлах, що взаємодіють один з одним за допомогою MPI. У цьому випадку вам хотілося б бути впевненими, що відправлені вами повідомлення прийдуть до ваших процесам і не будуть змішані з повідомленнями, відправленими між процесами зсередини бібліотечних функцій. p align="justify"> У цьому прикладі ми маємо три процеси, що взаємодіють один з одним. Кожен процес також викликає бібліотечну функцію та три паралельні частини бібліотеки взаємодіють один з одним. Нам хочеться мати два різних "простору" повідомлень, одні для наших повідомлень і один для бібліотечних повідомлень. Нам би не хотілося отримати будь-яке перемішування цих повідомлень. p align="justify"> Блоки представляють частини паралельних процесів. Час зростає зверху вниз на кожній діаграмі. Цифри в круглих дужках НЕ параметри, а номери процесів. Наприклад, send (1) означає відправку повідомлення процесу 1. Recv (any) означає отримання повідомлення від будь-якого процесора. Користувальницький (викликає) код знаходиться в білому (незатіненому) блоці. Затінений блок (викликається) являє собою пакет (паралельної) бібліотеки, викликаної користувачем. Нарешті, стрілки представляють собою переміщення повідомлення від відправника одержувачу. p align="justify"> Нижчеподана діаграма показує те, що б сталося, якби сталося те, що ми хотіли. У цьому випадку все працює, як намічено. br/>В
Тим не менше, немає ніякої гарантії, що події відбудуться в цьому порядку, так як відносне розклад процесів на різних вузлах може змінюватися від виконання до виконання. Припустимо, ми змінили третій процес, додавши деякі обчислення спочатку. Послідовність подій може виявитися наступною:
В
У цьому випадку комунікації не відбуваються як намічено. Перший "receive" у процесі 0 тепер отримує "send" з бібліотечної функції в процесі 1, а не намічений (і тепер затриманий) "send" з процесу 2. У результаті всі три процесу підвисають. p align="justify"> Проблема вирішується за рахунок того, що розробник бібліотеки запитує новий і унікальний комунікатор і визначає цей комунікатор у всіх викликах відіслати і отримати, які робляться бібліотекою. Це створює бібліотечне ("викликається") простір повідомлень окреме від користувальницького ("викликає") простору повідомлень. p align="justify"> Чи можна використовувати теги, щоб здійснити окремі простору повідомлень? Проблема з тегами полягає в тому, що їх значення задаються ...
