Formele Technieken in SWE Petri Nets - 2

Petri Nets t3t3 t2t2 t1t1 Plaatsen: passief, bevatten tokens (markering) Transities: actief, wijzigen de markering (vuurrij: rij transities die na mekaar vuren)

Ontwerp van een protocol voor mutual exclusion (ME) - specificatie We zullen een P/T net ontwikkelen voor een protocol met volgende beschrijving: Een eindig aantal computers gebruiken een gemeenschappelijke resource.Het is mogelijk dat sommige van deze computers de resource nooit vragen. Het protocol moet ervoor zorgen dat (1) de resource nooit aan meer dan één computer toegekend wordt, en (2) dat elke computer die de resource vraagt er ook ooit toegang toe krijgt.

ME protocol - algemeen Eerste benadering: • Algemene structuur • Precizeren van de specificatie • Environment (structuur van de client-computers)

ME protocol - algemene structuur Dit eerste voorstel voldoet niet: als de clients zich op verschillende locaties bevinden, zegt de centrale plaats res niets over de manier waarop ze communiceren. Ze kan niet opgevat worden als een communicatiekanaal. Een kanaal kan wel voorgesteld worden door een plaats, maar dan slechts tussen 2 partners (source en target).

ME protocol - algemene structuur Er zijn nu wel kanalen, maar er is een centrale server. Men bedoelt normaal met een protocol een gedistribueerd algoritme, met in principe identieke partners. Deze oplossing voldoet dus ook niet.

ME protocol - algemene structuur Dit is het soort model dat we zoeken: het protocol bestaat uit een aantal identieke componenten, die elk communiceren met één client en andere protocol componten. Deze communicatie verloopt dmv kanalen, die gemodelleerd zijn door plaatsen.

ME protocol - specificaties Voor het eerste deel van de specificatie, de eigenlijke ME eigenschap, is vrij duidelijk hoe we ze kunnen uitdrukken: we voorzien, per client, een plaats die uitdrukt dat die client de resource ter beschikking heeft, en we eisen dat er alleen markeringen bereikbaar zijn waarin zo maar één plaats een token bevat. Voor het tweede deel moeten is de situatie complexer: als we bv toelaten dat een transitie zomaar zonder reden “stilvalt”, dan kunnen we de gevraagde eigenschap duidelijk niet garanderen. We gaan daarom twee eigenschappen invoeren die we aan individuele transities kunnen opleggen: productiveness en fairness. We breiden de P/T taal dus uit.

Productiveness Een transitie t is productive als het volgende geldt: een eindige vuurrij eindigt niet in een markering waarin t enabled is, en in een oneindige vuurrij kan t niet aanhoudend enabled zijn zonder te vuren. Er blijft echter dit probleem: Kan hier de oneindige vuurrij t 1 t 2 t 1 t 2 …? t1t1 t2t2 t3t3

Fairness Een transitie t is fair als het volgende geldt: een eindige vuurrij eindigt niet in een markering waarin t enabled is, en in een oneindige vuurrij kan t niet oneindig vaak enabled zijn zonder te vuren. Faire en productive transities teken we in dit voorbeeld met volle lijn (default: productive), normale transities met stippellijn. Conflicten worden dus niet tot in het oneindige opgelost ten nadele van transitie t.

ME protocol - de clients cni: client not interested cint: client interested ccs: client in critical section crdy: client ready creq: client request cperm: client has permission clc: client leaves critical section cgi: client gets interested cec: client enters critical section kanalen toestanden

Algemene structuur - 2 clients Elke client communiceert dus met zijn lokaal protocol via 3 asynchrone kanalen

Specificatie (n clients) Eerste deel: Voor elke bereikbare markering m, en voor elke i,j tussen 1 en n, m(ccs i ) = 0 of m(ccs j ) =0 Tweede deel: Voor elke i, en vanuit elke markering m waarin m(creq i ) > 1, zal er in 0 of meer stappen een markering m' bereikt worden waarin m'(cperm i ) > 1 _ _

Design: plaatsen Elk lokaal protocol zal 3 plaatsen hebben die met de mogelijke toestanden van de client overeenkomen: ni (not interested), wt (waiting), cs (in critical section). Bovendien voorzien we de mogelijkheid dat het gebruikte token niet onmiddellijk terug in de ring gestuurd wordt, maar opnieuw gebruikt wordt. Daarvoor voorzien we een plaats ut (used token).

Design: channels Het lokale protocol i heeft 5 plaatsen die het gebruikt om te communiceren met de rest van het systeem: - Twee plaatsen van de token ring: tin i en tin i+1 (token in). - Drie plaatsen om met client i te communiceren: crdy i, creq i en cperm i.

Design: transities Eenmaal de plaatsen gekozen zijn, liggen de transities voor de hand: ut: use token rti: reuse token immediately lc: leave critical section gi: get interested rt: relay token st: send token

"token ring" staat voor de rest van de ring. Slechts voor één i

Invarianten Zoals al eerder opgemerkt vormen invarianten een belangrijk hulpmiddel bij het redeneren over het systeem, en dus bij het bewijs dat de eisen voldaan zijn. Laat i en j indices van clients zijn, tusssen 0 en n-1 dus. We vinden volgende invarianten: (1) Voor elke i, m(cni i ) + m(cint i ) + m(ccs i ) = 1 Elke client is in juist één van zijn states. (2) Voor elke i, m(ni i ) + m(wt i ) + m(cs i ) = 1 Elke protocol-component is in juist één van zijn states.

Invarianten (3) ∑ ( m(cs i ) + m(ut i ) + m(tin i ) ) = 1 Er is maar één token in de ring (4) Voor elke i, m(crdy i ) + m(cperm i ) + m(ccs i ) = m(cs i ) Koppeling protocol - client: het protocol is in cs vanaf het moment dat er permissie gegeven is, tot de client signaleert dat hij klaar is. (5) Voor elke i, m(cni i ) + m(creq i ) - m(crdy i ) = m(ni i ) Koppeling protocol - client: het protocol is in ni als de client in cni is, of er een request is, maar niet als er nog een token in crdy is. i

De eerste eis Het is duidelijk dat invarianten 3 en 4 samen garanderen dat er ten hoogste één i is waarvoor m(ccs i ) > 1 (en dus, m(ccs i ) =1 ). Dit is een safeness eigenschap: er gebeurt nooit “iets slechts” _

De tweede eis Dit is een liveness eigenschap: er gebeurt ooit eens “iets goeds”. Het is duidelijk dat we de tweede eis niet kunnen voldoen zonder eisen over productivity en fairness van transities. Meer bepaald kunnen we niet toelaten dat het token gewoon tot in het oneindige rondgestuurd wordt in de ring. We zullen daarom moeten aannemen dat de transities ut i fair zijn. Analoog voor de st i Van de andere transities nemen we aan dat ze productive zijn.

Algemene methode We moeten aantonen dat er, vanuit elke markering m waarin m(creq i ) > 1, in 0 of meer stappen een markering m' bereikt wordt waarin m'(cperm i ) > 1 We redeneren over een graph (proof graph) waarvan de knopen sets van markeringen voorstellen, met daartussen de stappen waarvan we zeker weten dat ze kunnen plaatsvinden (volle pijlen in de graph-voorstelling), en de stappen waarvan we alleen maar weten dat ze kunnen gebeuren als er aan een aantal bijkomende voorwaarden is voldaan (pijlen in stippellijn). Bovendien gaan we de sets door middel van de invarianten verfijnen, dwz opdelen in subsets (pijlen met een  ). _ _

Invarianten Door invarianten (4) en (5) op te tellen komt er m(cni i ) + m(creq i ) + m(cperm i ) + m(ccs i ) = m(cs i ) + m(ni i ) en als we (2) in rekening brengen: (6) m(cni i ) + m(creq i ) + m(cperm i ) + m(ccs i ) + m(wt i ) = 1 Uit alle invarianten samen volgt nu dat geen enkele plaats ooit meer dan één token bevat, en we zullen nu spreken over, bv, “een markering m waarin cni i ” in plaats van “een markering m met m(cni i ) > 1”. _

Proof graph: eerste versie In de graph stelt creq i de set van markeringen m voor zo dat m(creq i ) = 1. We weten dat bv. vanuit een markering van creq i een markering van wt i kan bereikt worden, maar met bijkomende voorwaarde dat er ook een token is in ni i.

Proof graph: tweede versie Toepassing van invariant (2) leert dat creq i kan opgesplitst worden in 3 deelgevallen: creq i  cs i, creq i  ni i, en creq i  wt i. Uit invariant (6) volgt dat dit laatste niet kan voorkomen, en verder is creq i  cs i gelijk aan creq i  cs i  crdy i, want cs i impliceert ¬ni i wegens (2) en vervolgens geeft (5) dat crdy i.

Proof graph: derde versie We kunnen nu wt i opsplitsen in 5 gevallen, door gebruik te maken van (3): we maken enkel een onderscheid tussen de index i zelf en de andere (dus de j  i). Anders gezegd, we doen even alsof er maar 2 clients zijn. (3) geeft 6 gevallen, maar wegens (2) is wt i  cs i niet mogelijk, dus blijven er 5 over.

Proof graph: derde versie (neem aan i  j) De fairness van st i en ut i garandeert dat de cycles ooit verlaten worden. Besluit: de tweede eis is voldaan.

Verwijderen van overbodige transities Het is niet moeilijk aan te tonen dat de transitie rti niet nodig was (maar misschien wel de efficientie verhoogt). In plaats van fairness kunnen we nu voor st i gewoon productiveness eisen.

Vermijden van de fairness-eis Het is niet zo eenvoudig om fairness concreet te implementeren. In het vereenvoudigde model moeten we nog steeds eisen dat de ut i transities fair zijn. Dat kunnen we vermijden door voor wt i een complementaire plaats ¬wt i in te voeren, en rt i maar toe te laten als ¬wt i een token bevat. Dat leidt tot het volgende net.

(de dubbele pijl stelt een self-loop voor)

Uitbreiding: request ring De beschreven oplossing is niet efficiënt omdat er ook tokens rondgestuurd worden als er geen enkele client geïnteresseerd is. Dat willen we verhelpen door request-messages rond te sturen in de richting tegengesteld aan de richting waarin de tokens reizen. Informele beschrijving: Een client heeft het token gebruikt en bezit het nog steeds: - als hij opnieuw in de kritische sectie wil stuurt hij een request. - als hij een request krijgt, dan stuurt hij het token naar zijn buur. Een client gebruikt het token: - alle binnenkomende requests moeten wachten. Een client heeft het token niet en is niet geïnteresseerd: - alle binnenkomende requests worden doorgestuurd. - als het token binnenkomt, dan wordt dat ook doorgestuurd. - als hij in de kritische sectie wil stuurt hij een request. Een client heeft het token niet en is geïnteresseerd: - als het token binnenkomt, dan gebruikt hij het. - alle binnenkomende requests worden doorgestuurd.

Request ring: algemene structuur

Request ring - eerste versie Er zijn nieuwe plaatsen rin i voor de request ring. De transities zijn: sr rr st sti ecnt ecut rti lc : send request : relay request : send token (nu alleen als er een request is) : relay token : enter critical section with a new token : enter critical section with a used token : reuse toke immediately (nu zonder wachten) : leave critical section

Request ring - eerste versie

Request ring - tweede versie Er zijn wat shortcuts die weg kunnen terwijl het net toch nog aan de voorwaarden voldoet:

Request ring - derde versie rr en rt moeten een lagere prioriteit krijgen dan st en ecnt. Dat kan weer door self-loops toe te voegen, één die rr verbindt met een complementaire plaats ¬ut van ut en één die rt verbindt met een complementaire plaats ¬wt van wt.