Administrace komentářů

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.