elektronická verzia publikácie - FIIT STU - Slovenská technická ...
elektronická verzia publikácie - FIIT STU - Slovenská technická ...
elektronická verzia publikácie - FIIT STU - Slovenská technická ...
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
Architektúry softvéru 93<br />
Základnou Hoarovou myšlienkou bolo, že dva procesy sa najjednoduchšie zosynchronizujú<br />
pri svojich vstupno/výstupných operáciách. Na to je potrebné splni práve dve<br />
podmienky:<br />
1. proces A musí oznámi, že je pripravený odovzda údaje procesu B,<br />
2. proces B musí oznámi, že je pripravený prija údaje od procesu A.<br />
Ak niektorá z podmienok nie je splnená, pripravený proces prejde do stavu akania až<br />
kým nie je pripravený aj druhý proces.<br />
V roku 1985 rozšíril tento systém tak, že každý proces mohol ma viacero vstupov,<br />
priom každý vstup mal urené podmienky na aktivovanie. Vždy mohol by aktívny len<br />
jeden vstup, ale pokia mali viaceré vstupy splnenú podmienku, vybral sa náhodne jeden<br />
z nich. Toto umožnilo modelova nedeterministické vykonávanie procesov.<br />
Hoare navrhol svoj systém len ako modelovací nástroj, neoakával, že sa využije<br />
v komerných aplikáciách. To sa aj potvrdilo, lebo sa zistilo, že tento systém má viacero<br />
vážnych nedostatkov.<br />
Prvým problémom bolo, že vyžadoval explicitné pomenovania. Každý proces musel<br />
pozna názvy všetkých procesov, s ktorými chcel komunikova. Nebolo tak možné vybra<br />
alternatívny proces na komunikáciu.<br />
Druhým problémom bolo, že systém nemal definované žiadne fronty (angl. queues)<br />
na ukladanie správ. Preto bola možná len synchrónna komunikácia. Na modelovanie nezávislého,<br />
asynchrónneho procesu spracovania údajov sa vkladal dodatoný proces, ktorého<br />
jedinou úlohou bolo podrža údaje, kým nie je pripravený aj prijímací proces.<br />
Posledným problémom bolo, že nebolo zabezpeené detekovanie ani ochrana pred<br />
uviaznutím.<br />
Hoarov systém však má zásluhu aj na tom, že sa tieto problémy objavili a vyriešili,<br />
takže v novších systémoch sa už zvyajne nevyskytujú.<br />
3.5.2 Systémy založené na udalostiach<br />
V systémoch založených na udalostiach sa nieo vykonáva len vtedy, ke nastane nejaká<br />
udalos. Zdroj udalosti pritom vôbec nemusí vedie kto jeho udalos spracuje a i ju vôbec<br />
niekto spracuje. Podobne príjemca udalosti sa tiež nemusí zaujíma o toho, kto tú udalos<br />
vytvoril. Dôležité je len aký je to typ udalosti a aké údaje s touto udalosou súvisia. Udalos<br />
sa v týchto systémoch prenáša ako správa, kde typ správy uruje typ udalosti a obsah<br />
správy reprezentuje údaje alebo odkaz na údaje, ktoré sa majú spracova.<br />
Na obrázku 3-14 je základná štruktúra systému založeného na udalostiach. Jeho podstatnou<br />
asou je manažér udalostí. V manažéri sa zaregistruje zdroj udalostí a oznámi aký<br />
typ udalosti bude posiela. Podobne sa tam zaregistruje aj príjemca udalostí a uvedie<br />
aký typ udalostí chce prijíma. Na základe registrácie sa nastaví smerova, ktorý prepája<br />
informácie od zdrojov k príjemcom.<br />
Od momentu, ke je zaregistrovaný aspo jeden zdroj a aspo jeden príjemca rovnakého<br />
typu udalostí, udalosti môžu by spracovávané. Zdroj aj príjemca sa tiež môžu kedykovek<br />
odregistrova. To umožuje úplnú nezávislos innosti jednotlivých súiastok.<br />
Každá súiastka potrebuje pozna výlune manažér udalostí. Manažér sa oboznámi<br />
s každou zaregistrovanou súiastkou, ale vždy pozná len tie aktuálne zaregistrované.