Dotaz: Uváznutí v Aktor systému

[BoneFlute]

Zdravím.

Zkouším si jednoduchý Aktor systém. Celkem mi to jakože pěkně funguje, ale trošku jsem se zasekl na uváznutí.

Předpokládejme dva aktory A a B.

A -> B: kolik je hodin
B -> A: 19:41
A -> B: supr, díky
B -> A: není zač
A -> B: ok
B -> A: ok
A -> B: ok
B -> A: ok
A -> B: ok
B -> A: ok
A -> B: ok
...

Mohl by mi tu někodo poradit, jak se něco takového řeší? Třeba v Erlangu, systému Akka, nebo dalších?

Nechce se mi spoléhat na to, že ten aktor bude napsán správně. Rád bych tomu dodal alespoň základní ochranu. V "normálním" kódu se to dá trochu statistickou analýzou podchytit. Na druhou stranu mé znalosti problematiky jsou omezené, a tak třeba existuje nějaké jednoduché řešení které dokáže víc.

Předem dík.

Odpovědi

[xkucf03]

Kdo definuje ten protokol a význam jednotlivých zpráv? Tam, kde je definováno, co znamená „ok“, by mělo být i definováno, jestli se na takovou zprávu má odpovídat.

K nějakému zacyklení nebo rekurzi může dojít všude. To je chyba návrhu. Určitý počet opakování nebo návrat k předchozím stavům či nějaká rekurze můžou být dokonce žádoucí – např. zadání může znít tak, že se má něco zkusit třikrát s nějakou prodlevou, a pak to teprve má jít jinou cestou (opustit cyklus, ukončit se). Tzn. přidáš si tam nějaké počítadlo. Ale jak říkám, to je otázka návrhu/zadání. Pokud máš chybné zadání nebo se jím neřídíš, tak ti žádná technologie nepomůže.

Ten návrh můžeš mít popsaný nějakým formálním jazykem a z něj generovat kód… pak bys mohl staticky analyzovat ten formální popis. Jestli ten kód píšeš ručně a jsou to prostě jen různé kousky kódu, které nějak reagují na nějaké události, ale není nikde zachycený ten logický model jako celek, tak se obávám, že to nelze. Leda k tomu psát automatické testy – ale tím neprokážeš, že to nikdy neselže – jen, že to v předpokládaných případech pracuje podle zadání.

P.S. upravil jsem formátování (přidal <pre/>)

[OldFrog {Ondra Nemecek}]

Myslím si to samé, už jsem odpovídal na totožný dotaz na root.cz. Postupně mi došlo, že tazatel asi chce obecnou prevenci zacyklení bez ohledu na protokol. Což nemá řešení a ani to nedává smysl.

[BoneFlute]

Díky za příspěvek.

[M. Ponkrác]

Myslím, že tu byl nedávno příspěvek, kdy se někdo snažil o "správný vzor návrhu vícethreadové aplikace".

Určité fungování jde zajistit jen pro určité architektury a případy. Obecně to nejde.

1) Určité zmírnění problému může spočívat v řešení, že se zprávám přidají priority důležitosti. Přednostně docházejí zprávy s vyššími prioritami. Můžete mít třeba zprávy "urgentní", "důležité", a pak zprávy "zahoditelné".

2) Dále třeba v tom, že sender musí "navázat spojení" a povolit příjem.

3) Pokud má actor frontu zpráv, je možné nad těmi zprávami dělat redukce a optimalizace. Tak jako to třeba dělá každý GUI ve své frontě zpráv.

4) Každý sender může mít "váhu", která se snižuje při příliš vysoké frekvenci zpráv, a postupně obnovuje při "rádiovém klidu". Ovšem je třeba u každého sendera dát jinou počáteční váhu, některé dvojice actorů potřebují intenzivně komunikovat.

5) Často se spojuje do jedné dvojice zpráva a případná odpověď na ní jako pár. Ovšem zatěžuje to zbytečně synchronizaci.

6) Dále je možné detekovat různá zablokování a nepříznivé stavy.

Je třeba ale napsat, že actor systém je založen na férovosti. Není určen pro neférové situace. Pokud v actor systému máte "záškodníka", tak vám ho rozloží snadno na atomy. Actor architektura se s tím prostě neumí vypořádat.

Většina různých paralelních systémů implementuje ty věci co jsem popsal výše, a ještě mnohé další. Především je řada zpráv zahoditelných zcela, když systém přestane stíhat časově.

Obecně nelze actor schéma učinit bezpečným a blbuvzdorným. Nejde to.

Co je ale dobré je učinit ho flexibilním pomocí zahazování zpráv a dalších instrumentů, pokud začne běžet na hormí mezi výkonu počítače/hardware.