V první přednášce býval vždycky algoritmus ukončení výpočtu, ve kterém si procesory postupně dokolečka posílají token, který obarvují. Podle toho, jakou barvu tokenu dostane odesílajícií uzel, se pak pozná , jestli je možne bezpečně skončit, protože už s tím všechny uzly počítají. K deadlocku v tom nemůže dojít. Dá se to použít na váš algoritmus třeba tak, že uzel s optimem pošle zprávu o tomto potěšitelném faktu řídícímu uzlu (0) a ten vyšle ukončovací token.
2 | No.2 Revision |
V třetí přednášce je (thx. @Filip Vondráček) první přednášce býval vždycky vždycky algoritmus ukončení výpočtu, ve kterém si procesory postupně dokolečka posílají token, který obarvují. obarvují (modifikovaný Dijkstrův algoritmus ukončení výpočtu). Podle toho, jakou barvu tokenu dostane odesílajícií uzel, se pak pozná , jestli je možne bezpečně skončit, protože už s tím všechny uzly počítají. K deadlocku v tom nemůže dojít. Dá se to použít na váš algoritmus třeba tak, že uzel s optimem pošle zprávu o tomto potěšitelném faktu řídícímu uzlu (0) a ten vyšle ukončovací token.
Jenom doplním pro případ, že by to nebylo zřejmé: Mechanismus zpracování zpráv v jednotlivých uzlech nesmí fungovat tak, že když vyšlu zprávu A, tak budu čekat na odpověďA a všechno ostatní zahazovat. Při čekání na odpověď musím přijímat i zprávy, které nejsou odpovědí, a nějak na ně reagovat. To platí obecně ve všech situacích. Speciálně ale pro čekání na odpověď "ukončuju výpočet" tedy musím umět řešit i všechny standardní zprávy - např. na požadavek o další práci mohu odpovědět "nemám", případně i "nemám, ukončuju se" (aby volající uzel věděl, že je zbytečné žádat další uzly a radši se také přepnul do stavu "ukončuju se"). Ale vlastní ukončení dělá až ten ukončovací token od řídícího uzlu.
3 | No.3 Revision |
V třetí přednášce je (thx. @Filip Vondráček) Vondrášek) první přednášce býval vždycky algoritmus ukončení výpočtu, ve kterém si procesory postupně dokolečka posílají token, který obarvují (modifikovaný Dijkstrův algoritmus ukončení výpočtu). Podle toho, jakou barvu tokenu dostane odesílajícií uzel, se pak pozná , jestli je možne bezpečně skončit, protože už s tím všechny uzly počítají. K deadlocku v tom nemůže dojít. Dá se to použít na váš algoritmus třeba tak, že uzel s optimem pošle zprávu o tomto potěšitelném faktu řídícímu uzlu (0) a ten vyšle ukončovací token.
Jenom doplním pro případ, že by to nebylo zřejmé: Mechanismus zpracování zpráv v jednotlivých uzlech nesmí fungovat tak, že když vyšlu zprávu A, tak budu čekat na odpověďA a všechno ostatní zahazovat. Při čekání na odpověď musím přijímat i zprávy, které nejsou odpovědí, a nějak na ně reagovat. To platí obecně ve všech situacích. Speciálně ale pro čekání na odpověď "ukončuju výpočet" tedy musím umět řešit i všechny standardní zprávy - např. na požadavek o další práci mohu odpovědět "nemám", případně i "nemám, ukončuju se" (aby volající uzel věděl, že je zbytečné žádat další uzly a radši se také přepnul do stavu "ukončuju se"). Ale vlastní ukončení dělá až ten ukončovací token od řídícího uzlu.