[Modelinterpreter] case study kerdesek

[Dévai Gergely]

Sziasztok!

Boldi, igazad van: Nem eleg a futaskesz activity-k halmazat megnezni ahhoz, hogy kideruljon kik futhatnak egymassal parhuzamosan. Minden olyan utasitasnal is el kell tudni vagni a vegrahajtast, ami uj futaskesz activity-ket generalhat. Ilyen pl. az uzenetkuldes, ami Te peldadban szerepel, de ilyen meg az uj aktiv objektumok letrehozasa es viselkedesuk elinditasa is. Ezek alapjan egy olyan megoldas korvonalazodik, hogy egy halmazban taroljuk a futaskesz es a megszakitott acivity-ket, a fenti kritikus utasitasok utan (potencialisan) megszakitjuk oket, logoljuk hogy ket megszakitas kozott milyen adatokhoz fertek hozza. Egy offline elemzes pedig megnezi, hogy a logolt hozzaferesek es a potencialisan parhuzamosan futo activity-reszletek nem vezetnek-e konfliktushoz.

DE. Egyre tobben mondjuk az ericssonosoknak, hogy a shared memory parhuzamossag tul sok problemat vet fel, ezert lehet, hogy csak arra az esetre kell megoldast szallitani, hogy egy komponensen belul minden szekvencialis, parhuzamossag csak az aszinkron kommunikalo komponenesek kozott lehet. Ez sokat egyszerusitene a feladatunkon.

Olyan architekturat kellene epitenunk, amiben hatekonyan meg tudjuk valositani ezt az egyszerubb esetet, de nem zarja ki, hogy kesobb igeny szerint plusz fejlesztes soran a shared memory parhuzamossaggal kapcsolatos teszteles/elemzes is megvalosithato legyen.

Udv,
Gergo


On Monday, November 17, 2014 13:32 CET, <nboldi at caesar.elte.hu> wrote:
 Sziasztok!

> Boldi: Ha abban gondolkozunk, hogy az allapotvaltasokhoz tartozo > aktivity-k nem uresek, es minden activity lefutasa utan automatikusan

Jogos a kérdés, de van olyan példa, amikor egy lehetséges interferenciát csak akkor tudunk észlelni, ha az egyes utasítások között történhet megszakítás.

Tegyük fel, hogy van két állapotautomata, "a" és "b", "a" éppen az "x" állapotba lép, mert kapott egy eseményt. Az "x" entry akciójában van egy olyan utasítás, hogy küldjön egy üzenetet "b"-nek. Persze ez csak bizonyos ritka együttállások esetén történik meg. Ettől "b" is aktívvá válik, megkaphatja a vezérlést. Viszont az az akció amit "b" csinál erre összeakadhat "a" maradék akciójával.

Emiatt a context váltások segítségével esélyünk van arra, hogy több információhoz jussunk. Persze biztosra nem mehetünk, de legalább esélyünk van a hibát detektálni. Ennek a megvalósítására jól használhatók a korutinok.

Alternatív lehetőség, hogy statikus elemzéssel nézzük meg, hogy egy akció milyen üzeneteket küldhet és az alapján figyeljük a lehetséges ütközéseket. Persze ennek az lehet a hátránya, hogyha mondjuk a "b" egy hibadetektáló komponens, sokan érhetik el és összegyűjt egy csomó információt a rendszerről, akkor mindenféle akcióval ütközni fog. Sok lesz a fals pozitív, viszont a valódi hibaeset nem jöhet elő az interpreterben ha itt csak statikus elemzést csinálunk ahelyett, hogy a vezérlést akárhol átadhatjuk.

Üdv,
Boldi


_______________________________________________
Modelinterpreter mailing list
Modelinterpreter at plc.inf.elte.hu
https://plc.inf.elte.hu/mailman/listinfo/modelinterpreter


 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://plc.inf.elte.hu/pipermail/modelinterpreter/attachments/20141117/1fa9eeab/attachment.html>