Párhuzamos programozást támogató nyelvi eszközök összehasonlítása: Grafikus segédeszközök párhuzamos programok készítéséhez

3. Grafikus segédeszközök párhuzamos programok készítéséhez

Ebben a fejezetben az objektum-orientált, párhuzamosságot támogató tervezési, tesztelési rendszer követelményeinek lefektetésével egy ilyen eszközrõl lesz szó.

3.1 Háttér

3.1.1 Tervezési módszer

• Objektumok, osztályok azonosítása: Ez a lépés alapvetõen a feladat felmérését és formalizálását jelenti. A fizikai és logikai objektumok azonosításával, majd hasonló tulajdonságaik alapján való osztályba szervezésével oldható meg.
• Objektum osztályok leírása: az osztály feladatainak leírása emberi nyelven, vagy valamilyen egyszerû formalizmus felhasználásával
• Objektumok jellemzõinek, attribútumainak meghatározása: ezzel a lépéssel lényegében az osztályok adattagjai, illetve azok értelmezési tartománya kerül meghatározásra
• Objektumok közötti kapcsolatok: az objektumok mûveleteinek meghatározása, illetve annak leírása, hogy mely más objektum, és milyen formában fogja használni az adott mûveletet.
• Öröklõdési összefüggések meghatározása: adat- és eljárás-absztrakciókkal létezõ osztályok összevonása.
• Modulba szervezés, láthatósági viszonyok rögzítése

Ezek a lépések párhuzamos környezetben a következõkkel egészülhetnek ki:

• Objektumok aktivitásának meghatározása: párhuzamos rendszerben lehetnek passzív, illetve aktív objektumok, melyek akkor is végezhetnek mûveleteket, amikor más nem szól hozzájuk.
• Szinkronizációs módszerek meghatározása: ezt a lépést az objektumok közötti kapcsolatok, illetve az objektum mûveleteinek meghatározásánál kell megtenni. Arra szolgál, hogy az objektum belsõ állapotától, illetve tevékenységétõl függõen a rajta elvégezhetõ mûveletek halmazát dinamikusan lehessen változtatni.
• Objektumok elhelyezése a fizikai processzorokon: az objektumrendszer elosztása egy párhuzamos számítógépen, hogy minél jobban kihasználja az erõforrásokat. Ez lehet statikus, vagy futás közbeni elosztási stratégia leírása is.

3.1.2 Nyelvek, eszközök

Objektum orientált és párhuzamosságot támogató elterjedt nyelvekbõl nincs sok. Mivel ez egy viszonylag új terület, ezért nagyon sok eszköz állhat egy programozó rendelkezésére, de ezek legtöbbje egy egyedi megoldás, valamilyen speciális probléma támogatására szolgál.

Az Ada 95 szabvány által meghatározott Ada nyelv egy megoldás lehet. Ennek elõnye, hogy megtervezték, és a két problémakört majdnem teljesen lefedi megoldásaival. A GNU project-ben készülõ GNAT fordító a nyelv legnagyobb részét implementálta, de a valódi több-processzoros rendszerek egyedi igényei miatt csak egy processzorra képes kódot készíteni.

A High Performance C++ nyelv egy C++ kiterjesztés, mely sok érdekes elemet tartalmaz a párhuzamosság támogatására. Ez még csak egy napjainkban fejlõdõ szabvány, de a hozzá készült minta-fordító már most is több platformon mûködik.

Ha csak az objektum orientáltságot kötjük ki, akkor a nyelvek választéka sokkal nagyobb. Ezekhez a nyelvekhez azonban illeszteni kell valamilyen párhuzamosságot támogató eszközt is.

Nyelvek közül a C++ és az Eiffel emelhetõ ki. Elõbbi az elterjedtsége, utóbbi a példa értékû objektum orientált megoldásai miatt.

Párhuzamosságot támogató eszközök közül is elterjedt megoldásokat érdemes választani, hogy az elkészített program hordozható legyen. Ilyen lehet a sok számítógépgyártó által támogatott PVM könyvtár, vagy az egyre inkább elterjedõ MPI szabvány.

3.1.3 Vizsgáló eszközök

• nyomkövetõ, hibakeresõ eszköz a program logikai hibáinak feltárására (ez párhuzamos esetben nagy mértékben bonyolódhat a végrehajtás többszálúsága miatt)
• hatékonyság tesztelése a program sebességének növelésére, illetve erõforrás-felhasználásának csökkentésére

3.2 Grafikus eszközök

3.2.1 Objektum orientált tervezés

Ennek a résznek a bevonása az eszközbe valószínûleg nem túl gazdaságos - vannak jobb és szebb szövegszerkesztõk és rajzolók -, de a késõbbi dokumentálások érdekében mégis érdemes lehet.

A program készítése során, illetve a végsõ dokumentáció összeállításakor kényelmes lehet a konkrét programrészekhez kapcsolni a mellékesen elkészített dokumentációkat. Ennek legjobb módja az lehet, hogy minden lépésnél, illetve programrészletnél valamilyen megjegyzést lehet írni, melybe más dokumentumokat is be lehet kapcsolni.

Ha a feladat leírása már megvan akkor ki lehet jelölni az alapvetõ fizikai és logikai objektumokat.

3.2.1.1 Statikus modell tervezése

Ábra 18. Banki pénzkiadó rendszer alapja

Az objektumokat objektum osztályokká alakítva kialakítható a statikus modell váza is.

Az osztályokkal kapcsolatban a következõ jellemzõket kell megadni:

• statikus kapcsolatok: tartalmazás, hivatkozás
• öröklõdési hierarchia
• osztályok attribútumai
• osztályokon végezhetõ mûveletek specifikációi

3.2.1.1.1 Statikus kapcsolatok

Ábra 19. Statikus osztálykapcsolatok

Ezek létezõ objektum osztályok között adhatóak meg.

3.2.1.1.2 Öröklõdés

Ábra 20. Öröklõdési kapcsolatok

3.2.1.1.3 Attribútumok, mûveletek

Érdekes lehetõsége lehetne az eszköznek, ha forráskódban definiált osztályokhoz is képes lenne grafikus ábrázolás generálására. Ezzel a módszerrel forráskódban meglévõ algoritmusok elemzése, esetleg párhuzamosítása is megkönnyíthetõ lenne.

A mûveletek meghatározásakor szekvenciális programoknál általában csak azok szintaxisát definiálják. Párhuzamos esetben ez nem mindig elég, a mûveletek szinkronizációját is meg kell határozni.

Legegyszerûbb esetben a programozó egyes mûveleteket kijelölve megadhatja, hogy azok csak egymást kölcsönösen kizárva futhatnak le (pl.: CC++ nyelv atomic kulcsszava).

Ez az egyszerû módszer persze sokszor nem elégséges, ezért ki kell terjeszteni valamilyen szinkronizáció specifikáló formalizmussal, melyekhez bonyolultságuk miatt nehéz bármilyen grafikus segédeszközt biztosítani.

Meg lehetne vizsgálni útkifejezésekkel, vagy õrfeltételekkel adott szinkronizációs specifikációk erõsségét, és használhatóságát is. Ebben a környezetben az öröklõdés és a szinkronizáció kezelése külön problémát jelentene, melynek megoldása nagy jelentõségû lépés lehet.

A statikus modell tervezése szekvenciális programok készítésénél is nagy segítség lehet.

3.2.1.2 Dinamikus modell tervezése

A statikus modellben meghatározott osztályokból létre lehet hozni objektumokat, melyek között kommunikációs kapcsolatokat lehet meghatározni.

Az objektumok önmagukban a következõ osztályokba sorolhatóak:

• szerver objektumok, melyek alapvetõen adatok eltárolására szolgálnak, és nem végeznek másokon mûveleteket
• aktor objektumok, melyek önmagukra nézve nem engednek meg mûveleteket
• ágens objektumok, melyek a fenti kettõ kombinációi

Ettõl a besorolástól függetlenül minden objektumról el lehet dönteni, hogy aktív, vagy passzív-e. Ez a besorolás az objektum elhelyezésére (passzív objektum akár lemezre is kerülhet ) is hatással lehet.

Aktív objektumok kijelölésekor, azok még egy mûvelettel, az objektum önállóan elvégzett munkájának leírásával bõvülhetnek (pl. run mûvelet, amit majd a rendszer hív meg amikor az objektum létrejön).

Objektumok közötti kommunikációs kapcsolatok leírására a statikus modellben használt kapcsolatokhoz hasonló megadási módszerek is elképzelhetõek, pl.:

Ábra 21. Objektumok dinamikus kapcsolata

A dinamikus kapcsolatok megadása az objektumok elhelyezését is befolyásolhatja (pl. nem kommunikáló objektumok más-más processzorokra kerülhetnek).

Kódgenerálás szempontjából is fontos lehet a dinamikus kapcsolatok megadása, hiszen a kommunikációban résztvevõ feleket egymás számára láthatóvá kell tenni (statikusan a forráskódban, illetve dinamikusan a futó programban kell lennie valamilyen mutatónak a másik félre).

3.2.2 Párhuzamosítás

3.2.2.1 Virtuális processzorok

Különálló virtuális processzorokon lévõ objektumok akár különálló processzorokra, illetve memóriákba is kerülhetnek (persze ez nem kötelezõ).

Ábra 22. Virtuális processzorok

Az objektumok csoportosítása történhet a felhasználó által fixen rögzített módon, vagy sémák alapján is.

Ha a programozó meg tudja határozni, hogy pontosan mennyi objektum van a rendszerben, akkor ezekhez el lehet készíteni a megfelelõ számú virtuális processzort, és a megfelelõ statikus hozzárendeléseket (folytonos vonal).

Ha az hozzárendelések nem ilyen fixek - elõre meg nem adható számú objektum van -, akkor az osztályokat is virtuális processzorokhoz lehet rendelni, mely hozzárendelés így egy sémát fog meghatározni a futás közben létrejövõ objektumok, illetve virtuális processzorok hozzárendelésére. Egy virtuális processzorhoz persze több osztály is csatolható, mely esetben a futtató rendszer feladata, hogy ezek az objektumok egy virtuális processzorhoz kapcsolódjanak.

Ha az objektumok száma nagyon nagy - például egy fizikai szimuláció részecskéinek objektumairól van szó -, akkor a fenti két módszer nem lehet elégséges. Ilyen esetekben az objektumokat valamilyen minta szerint kell elosztani a virtuális processzorok között:

Ábra 23. Elosztási minták

A minták akkor kerülnek felhasználásra, amikor a nagy számú objektumot el kell osztani a virtuális, illetve késõbb a valódi processzorok között. A szétosztás statikus, azaz az objektumok vándorlását a processzorok leterheltségétõl függõen nem támogatja.

3.2.2.2 Fizikai processzorok

Ábra 24. 2 dimenziós hálóban processzorok

A fizikai processzorok leírásánál a processzorok számán kívül a köztük lévõ kommunikációs kapcsolatokat is definiálni kell. Lényegében tetszõleges processzorokat tartalmazó gráf megadható, de az egyszerûbb használhatóság érdekében az eszköz tartalmazhat elõre definiált modelleket is (pl. 2D háló, 3D háló, hiperkocka stb.).

Legegyszerûbb esetben a fent definiált virtuális processzorokat sorban ki kell osztani a fizikai processzorok között, és amikor azok elfogynak, akkor az elosztást újra az elsõ processzornál lehet folytatni.

A rendszer viszont a program felépítésének mély ismerete miatt hatékonyabb elosztásra is képes lehet. Az osztályok közötti statikus, az objektumok közötti dinamikus kapcsolatok, valamint a virtuális processzorokon lévõ objektumok ismerete alapján a virtuális processzorok úgy is eloszthatóak a fizikai rendszeren, hogy a közöttük folyó kommunikáció minél kevesebb fizikai processzorok közötti kommunikációhoz vezessen. Ez az elosztási módszer persze sokkal bonyolultabb, de a programról közölt nagy számú információ erre is lehetõséget adhat.

3.3 Vizsgálatok

Ha mindez elkészül, akkor a program lefordítható és futtatható. A futás során jelentkezõ gondok orvoslására, illetve a futás javítására szolgálhatnak a következõ eszközök:

3.3.1 Nyomkövetés

3.3.1.1 Programkód nyomkövetése

Ha mélyebben bele lehet nyúlni a rendszerbe, akkor elképzelhetõ ezen nyomkövetõ programok összehangolása, esetleg egyetlen több szálat követni képes programba integrálása, mellyel a folyamatok idõben összehangolt (egyik se "szaladjon el" a másikhoz képest) vizsgálata is lehetséges.

A programkód követésének csúcsa az lehet, ha a statikus vagy dinamikus modell grafikus ábrázolásában is szemléltetni tudja a nyomkövetõ program az éppen végrehajtott program állapotát (pl. egy osztály adott mûveletének megfigyelésekor kiderülne, hogy az a mûvelet valójában melyik osztályhoz tartozik, vagy a dinamikus ábrában az attribútumok nevei mellett az aktuális értékük is szerepelne).

3.3.1.2 Kommunikáció nyomkövetése

A program pillanatnyi állapotának ábrázolása a virtuális processzorok, vagy a dinamikus modell grafikus ábrázolásában. Ezeken a helyeken meg lehetne jelölni az éppen aktív objektumokat/processszorokat, valamint az aktív kapcsolatokat. A kapcsolatokról külön kérésre le lehet kérdezni azok tartalmát, az átvitt adatok formáját, értékét:

Ábra 25. Pillanatnyi kommunikációk

A kommunikációk egymáshoz viszonyított vizsgálatát segítheti, ha azokat idõhöz kötve egy diagrammon is lehet ábrázolni:

Ábra 26. Kommunikációk az idõ függvényében

Ilyen ábrázolások virtuális processzorokra, illetve objektumokra lebontva is hasznosak lehetnek.

3.3.2 Részletek tesztelése

Ennek megoldására valamilyen formában az egyes objektumok mûveleteit interaktívan is meg kell tudni hívni, akár valamilyen távoli elérés módszerével is.

3.3.3 Hatékonyság vizsgálata

Ezt a módszer postmortem profiling-nak nevezik a program lefutása utáni vizsgálatok miatt.

3.3.3.1 Lokalizált hatékonyság

A grafikus rendszer itt is abban segíthet, hogy az egyszerûbb rendszerek - egy-egy folyamatra vonatkozó eredményeket - eredményeit összesíti, és a statikus modell ábráiba illesztve megjeleníti. A legtöbb idõt elhasználó mûveleteket, illetve osztályokat ki is emelheti - pl. piros színnel befestve -, hogy a fejlesztõ figyelmét felhívja a szûk keresztmetszetekre.

3.3.3.2 Teljes program hatékonysága

Ilyen esetek vizsgálatát segítheti az idõ függvényében megjelenített aktív és passzív szakaszok ábrája is (ez virtuális és fizikai processzorokra is vonatkozhat):

Ábra 27. Processzorok aktivitása

Pillanatnyi leterheltséget százalékos arányban is lehet ábrázolni egy-egy processzorra vonatkozóan, ha azon egyszerre több folyamat is futhat (több virtuális processzor van hozzá rendelve, vagy több aktív objektumot tartalmaz).

3.4 Az eszköz lehetõségei

Ez a tervezõrendszer egyes esetekben a végsõ program optimalizálását nagyban segíthetné, hiszen az objektum orientált tervezés támogatása miatt a program belsõ felépítésével, illetve adatfolyamával is tisztában lehet.