2009.03.16.
Bevezetés
Dr. Mileff Péter
A hardver fejlıdésének ellenére nem mondhatunk le a párhuzamos feldolgozás által nyújtott teljesítménynövekedésrıl. A párhuzamosítás több szinten történik: egyetlen processzoron belüli párhuzamosítástól egészen a szuper-számítógépek ill. komplett számítóközpontok szintjéig.
A különbözı szintő párhuzamosítások függnek egymástól eredıjük jelentkezik.
2
Az üzenetküldéses paradigma
Bevezetés
A teljesítménynövekedés eredménye:
A párhuzamos programot felfoghatjuk: egymástól független, egymással kommunikáló
(1) Korábban számítógéppel megoldhatatlan feladatok megoldása válik lehetıvé.
(2) Egyes problémák sokkal jobb „minıségben” oldhatók meg.
szekvenciális folyamatok halmazaként.
A kommunikációt tekintve ekkor kétfajta programozási paradigmáról beszélhetünk: Osztott memóriás modell: a futó folyamatok ugyanahhoz
a (nem feltétlenül fizikai) memóriához férnek hozzá. Üzenetváltásos modell: ○ minden egyes folyamat a többi által nem elérhetı memóriát
(3)bizonyos – megoldási idı szempontjából kritikus – feladatok gyorsabban oldhatók meg.
használ. ○ a kommunikációt pedig a folyamatok közötti (szinkron,
aszinkron) üzenetek biztosítják.
fontos például valós idejő alkalmazások esetén. 3
4
1
2009.03.16.
Üzenetküldő rendszerek szabványai
Az üzenetküldéses paradigma
Ha a modellünk üzenetváltásos modell, nem jelenti feltétlenül azt, hogy végül az implementált programnak is feltétlenül „üzenetváltásos” hardveren kell futnia.
A rendszerek fejlesztését alapvetıen két fontos irány segítette.
1. Parallel Virtual Machine (PVM) könyvtár Alapkoncepciója: heterogén hardverrel és szoftverrel
Azonban egyszerőbben és általában hatékonyabban implementálhatók üzenetváltásos architektúrákon.
rendelkezı, különbözı architektúrájú számítógépekbıl egy virtuális gépet épít fel.
2. Message Passing Interface (MPI) Jelenleg az üzenetküldéses paradigma szabványa.
1991 elsı verzió.
5
6
A PVM rendszer
PVM: Parallell Virtual Machine
Általában egy üzenetküldéses rendszer konkrét megvalósításának tekintik. Helyesebb ha egy üzenetküldéses rendszer
specifikációjaként fogjuk fel. (PVM kézikönyv)
Célja: egy olyan szoftverrendszer kifejlesztése, amely támogatja az elosztott alkalmazások készítését. Fıleg UNIX rendszerekben.
Csak kevés hagyományos értelemben vett
Fejlesztı: Oak Ridge National Laboratory
operációs rendszer szolgáltatást biztosít legfıbb profilja az elosztott alkalmazás-
elsı (nem nyilvános) változat 1989-ben.
komponensek kommunikációjának megszervezése.
Elsı publikus változat (2.0) a University of Tenessee-n
1991-ben. Teljesen újraírt 3-as sorozatszámú változat 1993.
„Virtuális számítógép” koncepció: lehetıséget ad több számítógép erıforrásainak összevonására. Egységes interface az összekapcsolódáshoz.
7
8
2
2009.03.16.
Heterogenitások
A PVM rendszer
C nyelven készült:
Architektúra: támogatott architektúrák a PC osztályú számítógépektıl egészen a szuperszámítógépekig terjednek.
Adatformátum: biztosítani kell, hogy egy üzenet különbözı architektúrájú feladója és címzettje megértik egymást.
Számítási sebesség: gondoskodni kel róla, hogy a virtuális gépet alkotó számítógépek számítási teljesítményüknek megfelelıen részesednek a feladatokból.
az alaprendszer a C és a Fortran nyelvet támogatja Minden modern nyelvhez készült interface.
C++ nyelvhez: PVM++ függvénykönyvtár. Alapkoncepciója a virtuális gép fogalma. A virtuális gépet erıforrások egy halmaza alkotja.
A PVM tervezésekor az egyik legfıbb alapelv a heterogenitás volt, egyazon virtuális gép elemei különféle módon
lehetnek heterogének.
9
10
A rendszer szerkezete
Heterogenitások
Processzorterheltség: A virtuális gépet nem feltétlenül dedikált számítógépek alkotják, más felhasználók is használhatják ıket.
Eljáráskönyvtár: amit a PVM-et használó
alkalmazásokhoz hozzá kell linkelni. PVM szolgáltatások. Önállóan futtatható PVM-démon (pvmd)
A gépek terheltsége folyamatosan változhat.
Két fıbb komponensbıl áll:
○ gépenként és felhasználónként egy-egy példányban fut
Hálózati terheltség: A virtuális gép részei különbözı hálózati architektúrákkal rendelkezhetnek
○ a PVM szolgáltatások tényleges implementációja itt van.
A legelsı gépen elindított pvmd démon a
mester pvmd (master pvmd) démon.
nagyon különbözı hálózati teljesítményt
○ Szerepe kitüntetett.
eredményezhet az egyes gépek között.
○ A további pvmd-ket általában a mester pvmd
indítja.
A heterogenitás jól kihasználható… 11
12
3
2009.03.16.
A pvmd folyamatok
A PVM elterjedtsége
A felhasználó jogaival futnak (Unix terminológia)
Így az egyes felhasználók virtuális gépei teljesen
A szabad elérhetısége.
függetlenek egymástól, konfigurációjuk is különbözı lehet.
Oka: Számos hardvergyártó a
többprocesszoros/elosztott számítógépeihez ilyen interfészt (is) biztosít. Az elkészített program hordozható is. A UNIX operációs rendszert bıvíti ki.
A PVM futási egysége a taszk Minden taszkot az adott gépen futó pvmd indít el. Minden taszk és pvmd egy egyedi azonosítóval van
○ Ezzel lehetıvé válik párhuzamos programok
ellátva, amely egy 32 bites egész szám.
szabványos UNIX környezetbe történı beágyazására. 13
14
PVM a gyakorlatban
PVM a gyakorlatban
Két számítógépbıl egyetlen virtuális gép:
A PVM nem biztosít eszközöket összetett alkalmazások komponenseinek automatikus párhuzamosításához.
Az egyes komponenseket különálló programokként kell megírni. (pl. Unix processzként)
Szinkronizációra/adatcserére kell a PVM-et használni.
mindkét gépen elindítjuk a (megfelelıen
felkonfigurált) PVM-démont, majd el kell indítani a PVM-et használó
alkalmazásokat.
Ha egy gépet több különbözı felhasználó akar egy virtuális géppé összekapcsolni: mindegyik felhasználónak saját PVM-démont kell
indítania Felhasználóként viszont elég csak egy PVMdémont futtatnia. ○ ez megszervezi a felhasználó összes (akár több is!)
elosztott alkalmazásának futtatását. 15
16
4
2009.03.16.
PVM támogatásai
Egy „mezei” UNIX processz bekapcsolódjon a virtuális gépbe.
Egy PVM-be kapcsolódott UNIX processz kilépjen a PVM által biztosított virtuális gépbıl.
PVM virtuális gép vázlatos felépítése
Lehetıség a PVM-processzek egymás közti kommunikációjára. PVM-processzek úgynevezett PVM-processzcsoportokba kapcsolására.
Biztosított egy-egy ilyen csoport összes tagja részére az üzenetküldés
is. Egy-egy csoportba új tag felvétele és tagok törlése a csoportból. 17
18
PVM üzenetek
A PVM kommunikáció egysége az üzenet.
A kommunikáció menete:
PVM üzenetek
Az üzenet elıször mindig a küldı taszk pvmd
folyamatához kerül,
A pvmd fogja továbbítani azt a címzett pvmd
folyamatához, amely végül eljuttatja a címzetthez.
A két pvmd közötti kommunikáció minden esetben UDP protokollon keresztül történik. elınye, hogy egyetlen kapcsolódási végpont segítségével
lebonyolítható az összes partnerrel a kommunikáció. TCP protokoll N gépbıl álló virtuális gép esetén minden
UDP protokoll miatt a PVM-nek kell gondoskodnia a csomagok veszteségmentes és sorrendhelyes célba juttatását. A taszkok és a lokális pvmd közötti kommunikációhoz TCP-t vagy UNIX domain socketeket használ.
Az üzenetek küldése és fogadása aszinkron módon történik.
Az újabb PVM verziókban lehetıség van az egyes taszkok közötti közvetlen kommunikációra is ehhez a PVM a TCP protokollt használja.
egyes gépen N-1 darab kapcsolódási végpontot igényelne. 19
20
5
2009.03.16.
PVM üzenetek
PVM indítása
Üzenet küldés: pvm_send hívás.
Azonnal visszatér mihelyt az üzenetet tároló pufferbıl az
üzenet rendszerpufferbe másolása befejezıdött.
A PVM virtuális gép felélesztéséhez el kell indítanunk az ehhez szükséges programot: PVM-démont: pvmd3 PVM konzol: pvm
Üzenetek fogadás: pvm_recv hívás. A lokális pvmd-tıl próbálja átvenni az üzenetet.
○ interaktívan kapcsolhatunk és törölhetünk gépeket a virtuális
Az üzenetekhez ún. üzenetcímkét (message tag) rendelhet a küldı taszk.
○ interaktívan indíthatunk (és lıhetünk le) PVM-processzeket.
gépbıl,
halt: lelövi az összes futó PVM-processzünket, és kilép a PVM-
bıl, leállítja a PVM démont.
A fogadó taszk pedig a küldı taszk azonosítója illetve az üzenetcímke alapján szelektálhat, hogy éppen milyen üzenetet szeretne fogadni.
spawn: új PVM-processzt indít. kill: egy futó PVM-processzt lelı. reset: lelövi az összes futó PVM-processzt a konzol kivételével,
a PVM-démonokat pedig nem bántja. 21
22
További függvények
A PVM processzek kezelése
numt = pvm_spawn( "progi1", NULL, PvmTaskHost, "macska", 1, &tids[0]);
Minden PVM-processz rendelkezik egy egész típusú processz-azonosítóval (tid).
Elindít a macska nevő hoston egy új PVM-processzt a progi1 nevő programból.
pvm_exit: Egy PVM-processz a pvm_exit eljárás végrehajtásával léphet ki a PVM felügyelete alól.
pvm_mytid: a saját tid lekérdezése. A függvény visszatérési értéke az új PVM-processz tid-je. Nincs paramétere.
pvm_parent: Egy PVM-processz a szülıjének a tid-jét kérdezheti le. Visszatérési értéke a szülıjének a tid-je. Nincs paramétere.
pvm_kill: Lelövi azt a PVM-processzt, amelynek a tid-jét megadtuk az argumentumában.
Hasonló a Unix pid szerepéhez, de nincs köze hozzá.
Új processz létrehozása (pvm_spawn): int pvm_spawn(char *task, char **argv, int flag, char *where, int ntask,
int *tids); task: az elindítandó PVM-processzt tartalmazó végrehajtható fájl neve. argv: az átadandó program-argumentumok. flag: speciális igények jelzése az új PVM-processz elindításával kapcsolatban. where: hol akarjuk a programunkat elindítani. ntask: hány példányban akarjuk a PVM-processzt elindítani. tids: az elindított PVM-processzek azonosítói (tid-ek). Visszatérési érték az elindított taszkok száma.
23
24
6
2009.03.16.
A PVM kommunikáció
Puffer allokálás/deallokálás allokálás/deallokálás
Kommunikáció: primitív, UNIX signal-okat használó kommunikációs eljárások
Üzenetküldés céljából több üzenet-puffert is allokálhatunk:
összetettebb adatszerkezetek/adatterületek processzek közötti
kijelölhetjük, hogy melyik legyen az aktív küldési
mozgatására is eszközök.
pvm_sendsig: A függvény segítségével egy adott signalt (UNIX signalt) küldhetünk valamelyik PVM-processznek.
pvm_notify:
illetve aktív fogadási puffer.
int pvm_notify(int about, int msgtag, int ntask, int *tids); Az about argumentumban specifikált esemény bekövetkeztekor egy üzenetet
küld a tids vektorban megadott tid-del azonosított PVM-processzeknek.
Küldési: adatok berakása függvényekkel, küldés céljából. Fogadási: adatok olvasása egy megkapott üzenetbıl. Ezek akár meg is egyezhetnek.
mstag az üzenet azonosítója.
25
26
Puffer allokálás/deallokálás allokálás/deallokálás
Puffer allokálás/deallokálás allokálás/deallokálás
új üzenet-puffer létrehozása: pvm_mkbuf
Argumentuma egy egész szám: a puffer tartalmának az
azonosítóját. Visszaadja a korábban aktív küldési puffer azonosítóját.
Buffer felszabadítása: pvm_freebuf Argumentuma az eldobandó üzenet-puffer egyedi
azonosítója.
Küldési buffer lekérése: pvm_getsbuf
Az aktív fogadási puffer megváltoztatása: pvm_setrbuf: Argumentuma megadja az új aktív fogadási puffer egyedi
Nincs argumentuma. Visszatérési értéke az aktuális
azonosítóját
(aktív) küldési puffer azonosítója.
Aktív küldési puffer megváltoztatása: pvm_setsbuf: Argumentuma megadja az új aktív küldési puffer egyedi
összeállítási módját értelmezését/reprezentációját írja le. Visszatérési értéke a létrehozott buffer azonosítója.
Visszaadja a korábban aktív fogadási puffer azonosítóját.
Fogadási buffer lekérése: pvm_getrbuf Nincs argumentuma. Visszatérési értéke az aktuális
(aktív) fogadási puffer azonosítója. 27
28
7
2009.03.16.
Processz csoportok
Processz csoport műveletek
A PVM rendszer lehetıséget nyújt processz-csoportok szervezésére.
pvm_joingroup: egy processz csoportaggá válik.
pvm_lvgroup: kilépés a csoportból.
pvm_gsize: egyetlen argumentuma a csoport neve. pvm_bcast: üzenetküldés a csoport összes tagjának.
visszatérési értéke egy csoporton belüli azonosító szám.
Egy PVM processz bármikor beléphet egy csoportba - ezzel
Argumentuma a csoport neve.
csoporttaggá válik - illetve bármikor kiléphet egy csoportból.
A csoportoknak név adható. ASCII karakterekbıl.
Mőveletek:
elsı argumentum a csoport neve; a második argumentum
az üzenet típusának az azonosítója.
Üzenet küldése az összes csoporttag számára. ○ az üzenet küldıje nem kell, hogy tagja legyen a csoportnak.
A csoporttagok állapotának szinkronizálása.
pvm_barrier: csoport szinkronizációja elsı argumentum a csoportnév; a második argumentum
pedig egy szám (count). a hívó PVM-processz blokkolni fog egészen addig, amíg
(count) darab csoporttag meg nem hívja e függvényt. 29
30
31
32
Összefoglalás
A PVM célja: egy egységes felületet biztosítása a párhuzamos programok
fejlesztésére valóban párhuzamos architektúrákon, illetve hálózatba kapcsolt számítógépeken. Szinte minden párhuzamosságot igénylı feladat megoldható több-kevesebb ráfordítással. ○ dinamikus folyamat kezelése miatt kliens/szerver alkalmazások
írására is alkalmas lehet. csak programok párhuzamosságát támogatja ○ Nincsenek benne eszközök adat párhuzamosság, illetve folyamat-szál, utasítás szintő párhuzamosság támogatására. Csak aszinkron, pufferelt üzenetküldés a kommunikációra. ○ az üzenetküldés szimmetrikus, és sorrendtartó.
8
2009.03.16.
Az MPI
Az MPI
MPI = rutinkönyvtár szabvány. üzeneteken alapuló kommunikáció szintaxisát és
A rutinkönyvtár implementációi két csoportba oszthatók:
1)
A hardvergyártók által készített, az általuk gyártott hardverre erısen optimalizált változatok. Olyan fejlesztések, ahol elsıdleges cél a lehetı legtöbb architektúra támogatása egy függvénykönyvtárban.
szemantikáját definiálja.
Története:
2)
1992-ben megalakult MPI Forum, amelynek számos nagy
hardvergyártó cég a tagja lett. 1994 – a szabvány elsı változata: MPI-1, majd MPI-2.
A különbözı implementációival készített MPI programok egymással kommunikálni nem képesek.
Kifejlesztésének célja: Egy széles körben használható, hordozható szabványt készítsenek
üzenetek küldésére.
A programok csak forrásszinten hordozhatók.
33
34
Áttekintés
Erősségek/hiányosságok
Erısségek:
A kommunikációs primitívek nagy száma.
A rutinkönyvtárral a következı feladatokat lehet megoldani:
Erısen típusos üzenetküldés és a kollektív
kommunikációs lehetıségek.
Pont-pont közötti kommunikáció
Hiányosságok:
Üzenetekben lévı típusok megadása
a szabvány nem definiál eljárásokat folyamatok
Kollektív kommunikáció
indítására, illetve dinamikus kezelésére. Az MPI-2 (1997) ezt pótolja nagyrészt, de ennek máig kevés implementációja van.
Csoportok, környezetek kezelése Folyamatok topológiába rendezése Néhány kiegészítı rutin a program környezetéhez
○ ezek is csak adott hardverre optimalizált változatok.
Segítség a teszteléshez
Hibatőrés támogatása is csak az MPI-2 –tıl.
MPI-1 szabvány elıírja a C és Fortran nyelvek támogatását, ehhez az MPI-2 szabvány a C++ nyelv támogatását is hozzávette. 35
36
9
2009.03.16.
Áttekintés
Implementációk
Az MPI nem definiál eljárásokat folyamatok indítására, illetve dinamikus kezelésére. A folyamatok általában önálló programok, melyeket egyszerre indítanak el. A programok nem feltétlenül azonosak, tehát MIMD stílusban is lehet párhuzamos programokat írni ezzel a könyvtárral. A programok belsı szerkezetét sem definiálja az MPI,
Sok párhuzamos számítógépgyártó elkészítette a saját eszközére optimalizált változatot. ezek mind kereskedelmi termékek.
Publikus változatok: Argonne National Laboratory / Missipi State University: MPICH Edinburgh Parallel Computer Centre: CHIMP
tehát lehetnek szekvenciálisak, de akár többszálúak is, az MPI mégis
Ohio Supercomputer Center: LAM
egy önálló folyamatnak tekinti. Többszálúságra nincs semmilyen támogatás, de az implementációk általában ügyelnek rá, hogy a rutinok ne okozzanak bajt ilyen környezetben sem.
Missisipi State University: UNIFY ○ ez csak a szabvány egy részét valósítja meg a PVM-re építve. University of Nebraska at Omaha: WinMPI
37
38
Felhasználói felület
Felhasználói felület
A felületben lévı rutinokra a következı fogalmak használatosak:
A szabvány a nyelvek közötti átjárhatóság biztosítása érdekében törekedett az egységes felület kialakítására, ezért nem használják ki mindig az adott nyelv által
lokális egy eljárás, ha csak egy folyamat belsı adataitól
biztosított lehetıségeket maximálisan.
függ, és befejezéséhez nem igényel kommunikációt más programokkal.
A szabványban leírt rutinok alakjai:
C nyelvben, ahol a visszatérési érték a rutin lefutásáról ad információt:
nem-lokális egy eljárás, ha a benne lévı mővelet más
folyamatokkal való kommunikációt is igényel. kollektív típusú egy rutin, ha egy csoportban minden
folyamatnak meg kell ıt hívni, hogy befejezıdhessen.
int MPI_Xxxxxxxx( ... ); 39
40
10
2009.03.16.
Kezdet és vég
Példaprogram
Az MPI függvények használata elıtt meg kell meghívni az MPI könyvtár inicializálását:
#include mpi.h
MPI_Init: parancssori argumentumokkal is foglalkozik, át
void main(int argc, char *argv[]) { MPI_Init(&argc, &argv); /* a program utasításai ide kerülnek */ MPI_Finalize(); }
kell adni neki.
A program normális befejezése: MPI_Finalize
Hiba esetén a párhuzamos program futása megszakítható az MPI_Abort eljárással.
A lefoglalt erıforrások felszabadítása.
nem csak az adott folyamat, hanem a hozzá tartozó
folyamatok is leállíthatók. Paramétere: comm - egy kommunikációs közeget ír le. 41
42
Pont--pont kommunikáció Pont
Pont--pont kommunikáció Pont
Mindig két taszk vesz részt benne.
Az egyik küldi a másik pedig fogadja az üzenetet.
Egy üzenet adattípusa: MPI_Datatype Új típusok is kialakíthatók struktúrák, illetve tömbrészletek
A pont-pont kommunikációk mindig megırzik az üzenetek sorrendjét. A legegyszerőbb küldı rutin az MPI_Send
leírására.
Egy üzenetben mindig benne van, hogy melyik folyamat küldte, mi az üzenet típusa, ki a címzett és mi a kommunikátor.
Üzenet fogadása: MPI_Recv
Az MPI könyvtárban definiált típusú adatvektor
elküldésére alkalmas. Címzés: ○ a fogadó sorszáma, ○ az üzenet típusa, ○ és az üzenet továbbítására szolgáló kommunikátor.
Blokkoló vétel. Az üzenet forrása és típusa elıírható, ○ az MPI_ANY_SOURCE, illetve az MPI_ANY_TAG használatával bárkitıl bármilyen üzenetet is lehet fogadni.
Ez egy blokkoló rutin. 43
44
11
2009.03.16.
Pont--pont kommunikáció Pont
Pont--pont kommunikáció Pont
MPI-ban a vett adatok egyszerő adattípusának meg kell egyeznie a küldött adatok egyszerő adattípusával.
Típusai:
Pufferelt vagy nem Pufferelt üzenetküldés: lokális eljárás, mert az üzenet továbbítása nélkül is véget érhet, hiszen egy helyi tárolóban még megırzıdhet annak tartalma.
Szinkron vagy aszinkron: Szinkron kommunikáció nem lokális; csak akkor fejezıdhet be, ha az üzenetet ténylegesen vették egy MPI_Recv rutinnal. A kommunikáció az MPI_Recv elıtt is elkezdıdhet.
Ready: Ez a kommunikáció, csak akkor sikeres, ha az üzenet küldést a másik oldal már várja, azaz végrehajtott már egy MPI_Recv függvényhívást. Ha a vevı oldal ezt nem tette meg akkor a mővelet eredménye definiálatlan.
egy bonyolult struktúra, vagy tömb vétele a küldésnél
felsorolt típusokra lebontva történik. ○ két { int, char } struktúra vehetı egyetlen { int,char,int,char }
struktúraként.
Az MPI nem gondoskodik típuskonverzióról - int típusú adatot nem lehet double-ként venni. Az eljárásnak a használt kommunikátort is specifikálni kell. A kommunikátorból megállapítható, hogy a folyamatok
azonos architektúrákon futnak-e. ○ ha nem, automatikus konverzió.
45
46
Nem blokkoló rutinok
Pont--pont kommunikáció Pont
A pufferelt, ready és szinkron üzenetküldések alakja csak a nevében tér el a MPI_Send-tıl:
A rutinoknak vannak nem blokkoló változataik. Ekkor a mővelet két részre bontható: egy kezdeti inicializáló rész, a mővelet befejezıdését vizsgáló részre.
MPI_Bsend - pufferelt. MPI_Ssend - szinkron. MPI_Rsend – ready.
Az ilyen felbontásnak akkor van értelme ha egy mővelet hosszú ideig tart és a várakozás helyett lehet hasznos számításokat is végezni.
47
A nem blokkoló rutinok mind egy MPI_Request típusú kérelmet használnak a háttérben futó mővelet jellemzıinek tárolására.
48
12
2009.03.16.
Nem blokkoló üzenet küldése
Háttérben futó eljárás vizsgálata
Az MPI számos lehetıséget biztosít. Pl.:
Nem blokkoló üzenetküldés: MPI_Isend Paraméterek egyeznek a blokkolóval kivéve az utolsót.
A mővelet végének megvárása, blokkolva a programot:
Az eljárás lefutása során inicializálja az utolsó paraméterként megadott MPI_Request típusú struktúrát.
Az MPI_Test eljárással meg lehet vizsgálni egy mőveletet.
Ez tárolja a függıben lévı, vagy háttérben futó eljárás jellemzıit. Ennek vizsgálatával megállapítható, hogy az üzenetküldés
MPI_Request_free szolgál a háttérben futó mővelethez
MPI_Wait Nem blokkol.
befejezıdött-e, vagy elıkerült-e valamilyen hiba.
tartozó jellemzıket leíró struktúra felszabadítására.
Az inicializálás után visszatér, és az üzenetküldés folyamata a program további futásával párhuzamosan fog megtörténni. A küldendı adatokat a mővelet befejezéséig nem illik bántani
Ha egy programban több nem blokkoló mővelet is van,
akkor ezeket egyszerre is lehet vizsgálni: ○ bármelyik befejezıdését meg lehet várni az MPI_Waitany
eljárással, ○ illetve bármelyik lefutását lehet vizsgálni az MPI_Testany rutinnal.
nem definiált, hogy mikor olvassa ki azokat a rendszer.
○ Csak egyetlen nem blokkoló mővelet befejezıdését figyelik.
MPI_Ibsend, MPI_Issend, MPI_Irsend
○ Összes mővelet megvárása: MPI_Waitall. 49
50
Az üzenetekben lévő típusok
MPI adattípus
Az üzenetek csak az MPI által ismert adattípusokat tartalmazhatják.
Leírja, hogy egymás után milyen egyszerő adattípusok
A rendszer csak alaptípusokat tartalmaz.
vannak, és az egyes elemek milyen eltolással vannak eltárolva.
Ha többre van szükség, akkor típuskonstrukciós
mőveletekre van szükség.
Egy egyszerő típusokból álló típus térkép:
Új MPI adattípus létrehozása: MPI_Datatype átlátszatlan típusból. A létrehozás után a típust engedélyeztetni kell az
MPI_Type_commit eljárással.
○ Elismerteti a rendszerben az új típust.
Egy adott adattípussal küldött MPI üzenet csak olyan MPI adattípussal vehetı, amiben az egyszerő adattípusok sorrendje és száma megegyezik a küldött MPI típuséval. Az MPI számos függvény biztosít az adatok menedzselésére: Pl.: MPI_Type_contiguous, MPI_Type_vector,
Az új típus bárhol használható az eddigi egyszerő
MPI_Type_struct, MPI_Type_free, stb…
típusok helyett, akár egy újabb típus létrehozására is. 51
52
13
2009.03.16.
Kollektív kommunikáció
Üzenet összeállítása Egy üzenet összeállítására az MPI_Pack eljárást lehet használni. Ez a rutin lényegében az MPI_Send-hez hasonló formában megadott adatokat másol be a felhasználó által elıre lefoglalt puffer területre. Többször meghívva tetszıleges adatokat lehet berakni egy üzenetbe.
A rutin addig vár, ameddig az összes folyamat meg nem hívja
Az így elıkészített üzenet puffert a szokásos MPI_Send rutinnal lehet
ugyanezt az eljárást.
elküldeni, csak MPI_PACKED paramétert kell megadni az üzenet adattípusaként.
Eljárás adatok lemásolása: MPI_Bcast. Egy kijelölt folyamat adatterülete lemásolódik a mőveletben
Az MPI_Unpack eljárással egy MPI_PACKED típussal vett üzenetbıl lehet kipakolni az adatokat.
résztvevı összes folyamat adatterületére.
Szintaxisa a bepakolásra hasonlít.
Kiemelt hangsúly a kommunikációs eszközökre. A PVM-hez hasonló szolgáltatások, függvények. Több folyamat szinkronizációja: MPI_Barrier.
○ közösen használt változók, paraméterek elterjesztésére szolgálhat.
A pakolt üzenetek küldésének kétségtelen elınye, hogy több lépésben is össze lehet állítani az üzenetet, de így az MPI semmilyen típusellenırzést nem tud végezni a küldött üzenetben.
Adatdarabkák összegyőjtése: MPI_Gather. Minden folyamat egy adott mennyiségő adatot küld el, ami egy
kijelölt folyamatban összegyőlik. 53
Csoportok, környezetek kezelése
54
Csoportok, környezetek kezelése
Az MPI lehetıséget biztosít folyamat csoportok, illetve kommunikációs környezetek kialakítására.
Kommunikációs környezetek: Arra szolgálnak, hogy egymástól független
kommunikációs rétegeket lehessen kialakítani egy programon belül, akár azonos folyamatok között. Ez a megosztás nem vertikális - mint a csoportosítás -, hanem horizontális. Üzeneteket csak egy kommunikációs környezetben belül lehet küldeni ○ más környezet számára nem látható és annak mőködését
nem zavarja.
Folyamatok csoportba rendezésével egyes problémák egyszerőbben leírhatók. A csoportba rendezés emellett lehetıséget biztosít a rendszer számára magasabb szintő optimalizációra.
MPI-ban a csoportok és a környezetek
összefogására szolgálnak a kommunikátorok. 55
56
14
2009.03.16.
Csoportok
Halmazműveletek
Az MPI-ban folyamatokat csoportokba lehet összefogni, hogy ezeket együttesen lehessen kezelni a program hátralévı részében.
A csoportok folyamatok rendezett halmazai, melyben
Csoportok összehasonlítása:MPI_Group_compare
minden folyamatnak egy sorszáma van.
A csoportokra többféle halmazmőveletet támogat az MPI. Egyéb mőveletek:
Mérete: MPI_Group_size
Csoportok leírása: MPI_Group átlátszatlan típussal. A csoportok kialakítására szolgáló mőveletek mind lokálisak.
A nem használt csoportokat a MPI_Group_free
mővelettel lehet felszabadítani.
Nem igényelnek kommunikációt más folyamatokkal. Az így létrehozott csoportok folyamatonként eltérıek
lehetnek.
57
58
Kommunikátorok
Kommunikátorok
A kommunikátorok a csoportok és a környezetek összefogására szolgálnak.
Minden kommunikációban meg kell adni egy ilyen
Hatására a régi kommunikátor folyamat csoportja
kommunikátort.
MPI_Comm_dup: Egy régi kommunikátor lemásolása. megmarad, de létrejön egy új kommunikációs környezet.
Új kommunikátort létrehozása egy csoportból: MPI_Comm_create.
Az új kommunikátor létrejöttekor a benne lévı folyamatok egy kollektív mővelet során kialakítanak egy új kommunikációs környezetet is
MPI_Comm_split: egy kommunikátor részekre bontása. A résztvevı folyamat megmondhatja, hogy az új
kommunikátorok közül melyikben szeretne benne lenni.
ezért az új kommunikátorban küldött üzenetek nem
keveredhetnek a korábbiakkal. 59
Egy kommunikátort az MPI_Comm_free eljárással lehet felszabadítani. 60
15
2009.03.16.
Összefoglalás
MPI szabvány Jól látszik, hogy egy jól átgondolt és sok szakértı
közremőködésével létrehozott rendszer. Az üzenetküldés területen szinte minden fontos
gondolatot ötvöztek benne.
A rendszerrel szinte mindenféle feladat megoldható. A könyvtár kifejezetten párhuzamos folyamatok közötti
kommunikáció támogatására íródott, nem tartalmaz elemeket adat párhuzamosság
kezelésére. 61
16