Grafické znázornění vláken a klasické problémy synchronizace

Transkript

1 Grafické znázornění vláken a klasické problémy synchronizace Naďa Jašíková Vít Koumar Jindřich Samec 1

2 Grafické znázornění vláken a jejich komunikace v UML Unified Modelling Language (UML) se používá k abstraktní vizualizaci modelů systémů, nejčastěji se jedná o softwarové projekty. Zahrnuje několik diagramů kterými lze vývoj projektu mapovat. Každý z těchto diagramů poskytuje jiné možnosti pro vizualizaci a má rovněž jiný účel a cílového uživatele. Diagram tříd (Class Diagram) slouží především programátorům a analytikům k jednodušší orientaci v kódu, diagram případů užití (Use-Case Diagram) poslouží k testování aplikace a také k funkčnímu popisu pro zákazníka. Ke znázornění vláken a komunikace zatím neexistuje standard ani v rámci UML. Pro naši práci jsme vybrali dva diagramy, sekvenční diagram (Sequence Diagram) a diagram aktivit (Activity Diagram). Sekvenční diagram Sekvenční diagram umožňuje znázornit několik objektů a posílání zpráv mezi těmito objekty. Respektuje přitom linii času, takže události jsou rozloženy chronologicky seshora dolů. Objektem v případě paralelního programování rozumíme vlákno a zprávy mezi objekty tak představují komunikaci mezi vlákny. Na následujícím obrázku je příklad sekvenčního diagramu, který znázorňuje jeden z klasických problémů synchronizace vláken - problém večeřících filosofů. Konkrétně je na obrázku vidět situace deadlocku, tedy stav, kdy má každý z filosofů (resp. procesů) uchopenou pravou vidličku (resp. alokován jeden ze dvou zdrojů nutných k činnosti procesu) a marně čeká na levou vidličku (tedy na druhý zdroj). Výsledkem je, jak známo, několik mrtvých filosofů kolem stolu plného jídla. Konkrétní stavy objektů jsou znázorněny modrými obdélníčky podél životní čáry objektu. 2

3 Obrázek 1 - Sekvenční diagram: Problém večeřících filosofů Diagram aktivit Diagram aktivit je dalším z diagramů, jež může pomoci při návrhu multi-vláknové aplikace. Nelze sice bez obtíží znázornit několik vláken a pro účely diagramu to ani není nutné - představuje totiž přehledný popis životního cyklu objektu (resp. vlákna) spolu s přechodovými aktivitami a momenty rozhodování. Na obrázku níže je diagram aktivit opět pro problém večeřících filosofů. Tentokrát ale můžeme sledovat stavy, kterými filosof prochází. 3

4 Obrázek 2 - Diagram aktivit: Problém večeřících filosofů 4

5 Další možnost vizualizace vláken Jako další příklad možnosti vizualizace vláken a jejich komunikace zde uvádíme postup použitý ve vývojovém prostředí Jitan Environment navrženém pro vývoj multivláknových aplikací v Javě. Jitan je vyvíjen na univerzitě v Nice projektem OASIS. Způsob v Jitanu použitý se nám zdál vcelku přehledný a použitelný, leč jde pouze o diagramy zachycující jednotlivé stavy vláken a objektů v čase a nelze v něm tedy pomocí jednoho obrázku zachytit způsob komunikace vláken. Pouze jejich reálný vývoj při běhu aplikace. Jitan používá pro znázornění vlákna či objektu elipsu uvnitř s názvem vlákna či objektu. Barva vnitřku elipsy zachycuje stav vlákna (tedy stavy jako runnable, dead, executing apod.). U objektů barva vyjadřuje, je-li objekt zamčen či nikoli. Komunikace mezi vlákny je znázorněna pomocí orientovaných hran, které ještě navíc mohou obsahovat upřesňující informaci. Takováto informace může být například, zda dané vlákno má zámek k nějakému objektu (na hranu je přidáno kolečko s písmenem L jako Lock), zda vlákno čeká až se uvolní zámek objektu držený jiným vláknem (kolečko s písmenem B jako blocked) či zda spí (kolečko s písmenem D jako Dormant). Možné stavy znázorňuje poslední obrázek. Následující obrázek zachycuje ukázku stavu průběhu programu řešícího klasický Problém producenta a konzumenta. V tuto chvíli je vlákno main mrtvé, vlákno Consumer2 spí a čeká až Producer4 zapíše data do objektu CubbyHole1. Vlákno Producer4 provádí synchronizovanou metodu a vlastní tedy zámek objektu CubbyHole1 a vlákno Consumer5 je blokováno tímto zámkem a stejně tak jako vlákno Consumer2 čeká na vydání zámku. Tímto způsobem se dají postihnou i velice složité mezivláknové komunikace. 5

6 Obrázek 3 - Zobrazení problému Producent-Konzument v Jitan Environment Obrázek 4 - Možné stavy vláken v Jitan Environment 6

7 Grafické znázornění vláken Petriho sítěmi Petriho sítě jsou matematické modely jimiž lze popisovat toky a závislosti informací uvnitř modelovaných systémů. Notaci Petriho sítí stanovil v 60. letech C.A.Petri. Za doby jejich existence se rozšířili o další skupiny sítí. Např. barevné Petriho sítě nebo Petriho sítě s časem. Základy Petriho sítí Základními entitami Petriho sítí jsou přechody (transitions) a místa (place). Místa představují podmínky a přechody představují události, které mají vstupní a výstupní podmínky. Přechody a místa jsou navzájem spojena orientovanými hranami (arcs). Každá hrana může spojovat pouze místo s přechodem nebo přechod s místem. Nikdy ne dvě místa nebo dva přechody. Místa mohou obsahovat libovolný počet teček (tokenů) představující aktuální stav Petriho sítě. Rozložení teček v Petriho síti se nazývá označkování (marking). Přechody odpalují tečky ze vstupních míst do výstupních. Přechod lze provést, pokud je ve vstupním místě alespoň jedna tečka. Odpálením přechodu se tečka odebere ze vstupního místa a přesune se do místa výstupního. Obrázek 5 - Příklad notace Petriho sítí 7

8 Základní řídící struktury v Petriho sítích Níže jsou zakreslené základní řídící struktury v Petriho sítích. sekvence větvení cyklus 8

9 Klasické problémy synchronizace producent-konzument problém večeřících filozofů bankéřův problém problém spícího holiče problém kuřáků cigaret problém čtenářů a písařů Pro zobrazení klasických problémů synchronizace jsme zvolili Petriho sítě. Toto vyjádření komunikace a běhu vláken se nám zdálo nejnázornější Producent-konzument v Petriho sítích spolu s pseudokódem. Tímto pseudo kódem je zapsán problém producent konzument a dále je znázorněn Petriho sítěmi. semaphore full = 0 semaphore empty = BUFFER_SIZE procedure producer() { while (true) { item = produceitem() down(holes) putitemintobuffer(item) up(data) } } procedure consumer() { while (true) { down(data) item = removeitemfrombuffer() up(holes) consumeitem(item) } } V diagramu Petriho sítí jsou po stranách znázorněna vlákna producent a konzument. Mezi těmito vlákny jsou dvě místa - semafory, které určují zda má vlákno čekat nebo nebo pokračovat dál v činnosti. Šipka od semaforu k místu znamená stav wait, šipka od místa k semaforu značí notify. Postup: 9

10 1. Producent čeká až ho semafor pustí k vytvoření dalších prvků. Stav na obrázku odpovídá situaci, kdy dává semafor volno a producent může vytvářet další data. 2. Producent vytvoří data a uloží je do bufferu. 3. Upozorní spotřebitele, že jsou data k dispozici. Tečka se zobrazí v místě Data 4. Semafor pustí čekajícího konzumenta dál, konzument data zpracuje a upozorní producenta, že je potřeba vytvořit data další. Tečka se přesune do místa Holes Obrázek 6 - Problém Producent-Konzument v Petriho sítích 10

11 Problém spícího holiče v Petriho sítích Obrázek 7 - Problém spícího holiče v Petriho sítích Inicializace Semaphore Customers = 0 Semaphore Barber = 0 Semaphore accessseats (mutex) = 1 int NumberOfFreeSeats = N Holič (Thread/Process): while(true) { P(Customers P(accessSeats) NumberOfFreeSeats++ V(Barber) V(accessSeats) } 11

12 Zákazník P(accessSeats) if ( NumberOfFreeSeats > 0 ) { NumberOfFreeSeats V(Customers) V(accessSeats) P(Barber) } else { V(accessSeats) } Problém večeřících filosofů Obrázek 8 - Problém večeřících filosofů v Petriho sítích 12

13 Bankéřův problém Obrázek 9 - Bankéřův problém v Petriho sítích Problém kuřáků cigaret Tento problém má na analogii kuřáků cigaret osvětlit synchronizační problém přístupu více vláken ke stejnému objektu. Analogie je následující. Máme stůl a u stolu sedí tři těžcí kuřáci a jeden rozhodčí (v anglických materiálech označován jako agent ). K přípravě cigarety je zapotřebí vlastnit tabák, papírky a zápalky. Každý ze tří kuřáků pak vlastní právě jednu z 13

14 těchto surovin v neomezeném množství. Rozhodčí vlastní všechny tři suroviny v neomezeném množství (v některých zdrojích se uvádí, že agent nevlastní žádné suroviny, ale pouze vybírá, kteří dva kuřáci mají dát svou surovinu třetímu, aby si tento mohl cigaretu připravit, na samotném problému to však nic nemění). Proces probíhá tak, že rozhodčí náhodně (nedeterministicky) vybere dvě suroviny, položí je na stůl a upozorní kuřáka s třetí surovinou, že si je může vzít. Ten, pokud zrovna nekouří, suroviny vezme, uvědomí o tom rozhodčího, připraví si cigaretu a nějaký čas kouří. Mezitím již rozhodčí vybral další dvě suroviny a upozornil dalšího kuřáka. Upozornil-li opět toho samého kuřáka musí čekat, dokud si tento suroviny nevezme. Do té doby se tedy nic neděje. Tak tento proces pokračuje stále dokola. V tomto případě představuje sdílenou datovou oblast stůl. Rozhodčí na něj nesmí nic položit, pakliže na něm stále je nesebraná surovina a kuřák musí brát ze stolu pouze tehdy, leží-li na něm správná surovina. Tedy analogie problému zápisu a čtení z a do jednoho místa více vlákny. V tomto případě potřebujeme ošetřit výše zmíněné dva problémy. Oběma problémům se můžeme vyhnout použitím binárního semaforu. Binární semafor je takový semafor, který zná pouze dva stavy 0 a 1 či zamčeno a odemčeno. Můžeme jej v tomto případě použít, protože je-li něco na stole (např. data uložena do sdíleného objektu) už na něj nesmí být položena ani jedna další surovina. Semafor je objekt se dvěmi metodami wait() a signal(), datovým atributem counter typu Integer s počáteční nezápornou hodnotou a polem vláken queue[] pro uchování fronty čekajících vláken na semaforu. Zavolá-li nějaké vlákno metodu semafor.wait(), pak je-li counter větší než 0, pak vlákno pokračuje v provádění kódu, je-li však counetr roven 0, vlákno se uspí a semafor si jej uloží do fronty čekajících vláken. Zavolá-li nějaké vlákno metodu semafor.signal(), pak je-li fronta neprázdná, vybere náhodně nějaké vlákno ke zpracování, je-li však fronta prázdná zvýší hodnotu counteru o 1 a vlákno pokračuje v běhu. První problém tedy řeší jeden semafor pro agenta, který mu oznámí, je-li či není-li na stole surovina. Druhý problém v našem případě řeší semafory tři (počet semaforů odpovídá počtu kuřáků). Každý kuřák podle toho co potřebuje čeká na příslušném semaforu, který dostane signál od rozhodčího, čímž rozhodčí kuřákovi signalizuje, že na stole je jeho vytoužená surovina. Takovýto problém může při vícevláknovém programování nastat, když potřebujeme předávat data mezi více vlákny za pomocí jednoho paměťového místa a ještě k tomu potřebujeme zajistit, aby vlákna která čtou četla pouze v okamžiku, kdy zapsaná data jsou určena právě jim. Následující schéma Petriho sítě zobrazuje Problém kuřáků cigaret. Levá strana schématu znázorňuje průběh cyklu uvnitř vlákna Agent a pravá strana znázorňuje kuřáka. Na začátku čeká agent na ingredience (či je pouze vybírá, budeme-li uvažovat, že agent má své suroviny), což znázorňuje stavové kolečko, které je na začátku běhu programu s jedním tokenem, tedy agent vybírá ingredience (či data pro zápis). Má-li je připraveny, položí 14

15 je na stůl a upozorní kuřáka, který je potřebuje. Tedy zapíše data a zavolá na příslušném semaforu metodu signal(), což znázorňuje přechod na stav čekám na prázdný stůl a na semafor pro příslušného kuřáka. Pak se přesune do stavu, kdy čeká až bude stůl prázdný. Na to reaguje kuřák, který byl informován tím, že nekoří-li zrovna, sebere ingredience ze stolu a přes tento přechod se dostane do stavu stůl je prázdný. Na to reaguje přechodem na semafor agenta, čímž ho informuje, že stůl je prázdný a sám se odebere od stolu a jde kouřit. Agent ihned vybírá další ingredience a vrací se na začátek. Kuřák po dokouření opět usedá za stůl a pokračuje od začátku. Obrázek 10 - Problém kuřáků cigaret v Petriho sítích Problém čtenářů a písařů Tento problém je velice podobného ražení jako problém předešlý, až na drobné rozdíly. V tomto problému jde o to, že máme skupinu čtenářů a skupinu písařů, kteří používají stejnou plochu na své čtení a psaní. Aby jejich činnost probíhala bez chyb, je nutné zajistit, aby více písařů nezapisovalo v jeden okamžik a aby čtenáři nečetli ve stejný okamžik, kdy dochází k přepisu předchozího záznamu, jelikož by si s největší pravděpodobností přečetli i kus zápisu z minula. S tímto zadáním se pojí jisté problémy, které musíme vyřešit. Máme-li zajistit, aby písař nezapisoval, když nějaký čtenář čte, nemůžeme sdílený objekt jednoduše uzamknout, jelikož by pak docházelo k podoptimálnímu využití času čtenářských vláken, kterým by nic nemělo bránit, aby jich četlo více najednou. Dále, může-li tedy více čtenářů číst najednou, musíme zařídit, aby nedocházelo k tomu, že noví a noví čtenáři budou žádat o čtení a písaři se nikdy nedostanou na řadu. Je tedy třeba zajistit, aby písař čekající ve frontě na semafor v ní čekal 15

16 jen po dobu nezbytně nutnou. Tyto obtíže lze vyřešit použitím jednoho společného semaforu. Tentokrát však již ne binárního, neboť potřebujeme zajistit, aby čtenáři mohli číst současně, kdežto písař musí být to jediné vlákno, které má v tu dobu přístup ke sdíleným datům. Tento postu znázorňuje další schéma v Petriho sítích. Levá část schématu znázorňuje čtenáře a pravá písaře. Na začátku je semafor otevřen jak psaní tak čtení, dle toho kdo se první přihlásí. Counter semaforu je na začátku nastaven na 10, ale pouze v našem ilustračním příkladě. V reálu se tato hodnota nastaví dle toho jak moc často se mezi čtenáře má vložit písař. Čím je tato hodnota menší, tím je pravděpodobnější, že časové úseky mezi jednotlivými zápisy budou kratší, protože tímto číslem se omezí maximální počet souběžných čtenářů, čímž se snižuje doba po kterou čeká písař ve frontě. Ze schématu plyne, že zavolá-li písařské vlákno metodu semafor.wait(), pak se counter sníží v tomto případě o rovných deset, čímž se zajistí že si do doby, než nedopíše žádné vlákno ani nezapíše ani nezačte. Zavolá-li metodu wait() čtenář, pak se sníží counter o jeden (v Petriho síti se odebere jeden token z kolečka znázorňujícího semafor), čímž se zajistí, aby nemohlo v tuto chvíli dojít k zápisu, ale můžou se stále hlásit další čtenářská vlákna o přístup k datům až do doby, kdy se counter sníží na 0. Pak může začít zápis nebo opět čtení. Obrázek 11 - Problém čtenářů a písařů v Petrho sítích 16

17 Zdroje