elektronická verzia publikácie - FIIT STU - Slovenská technická ...

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