formele technieken in swe petri nets - 2. petri nets t3t3 t2t2 t1t1 plaatsen: passief, bevatten...
TRANSCRIPT
Formele Technieken in SWE
Petri Nets - 2
Petri Nets
t3
t2
t1
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 t1t2t1t2 …?
t1
t2
t3
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 metvolle 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 interestedccs: client in critical section
crdy: client readycreq: client request cperm: client has permission
clc: client leaves critical sectioncgi: client gets interestedcec: 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(ccsi) = 0 of m(ccsj) =0
Tweede deel:
Voor elke i, en vanuit elke markering m waarin m(creqi) > 1, zal er in 0 of meer stappen een markering m' bereikt worden waarin m'(cpermi) > 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: tini en tini+1 (token in).
- Drie plaatsen om met client i te communiceren: crdyi, creqi en cpermi .
Design: transities
Eenmaal de plaatsen gekozen zijn, liggen de transities voor de hand:
ut: use tokenrti: reuse token immediately lc: leave critical sectiongi: get interested rt: relay tokenst: 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(cnii) + m(cinti) + m(ccsi) = 1 Elke client is in juist één van zijn states.
(2) Voor elke i, m(nii) + m(wti) + m(csi) = 1 Elke protocol-component is in juist één van zijn states.
Invarianten
(3) ∑ ( m(csi) + m(uti) + m(tini) ) = 1 Er is maar één token in de ring
(4) Voor elke i, m(crdyi) + m(cpermi) + m(ccsi) = m(csi) 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(cnii) + m(creqi) - m(crdyi) = m(nii) 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 samengaranderen dat er ten hoogste één i is waarvoorm(ccsi) > 1 (en dus, m(ccsi) =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 uti
fair zijn. Analoog voor de sti
Van de andere transities nemen we aan dat ze productive zijn.
Algemene methode
We moeten aantonen dat er, vanuit elke markering m waarin m(creqi) > 1, in 0 of meer stappen een markering m' bereikt wordt waarin m'(cpermi) > 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 erm(cnii) + m(creqi) + m(cpermi) + m(ccsi) = m(csi) + m(nii)en als we (2) in rekening brengen:
(6) m(cnii) + m(creqi) + m(cpermi) + m(ccsi) + m(wti) = 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 cnii” in plaats van “een markering m met m(cnii) > 1”. _
Proof graph: eerste versie
In de graph stelt creqi de set van markeringen m voor zo dat m(creqi) = 1. We weten dat bv. vanuit een markering van creqi een markering van wti kan bereikt worden, maar met bijkomende voorwaarde dat er ook een token is in nii.
Proof graph: tweede versie
Toepassing van invariant (2) leert dat creqi kan opgesplitst worden in 3 deelgevallen: creqi csi , creqi nii , en creqi wti . Uit invariant (6) volgt dat dit laatste niet kan voorkomen, en verder is creqi csi gelijk aan creqi csi crdyi , want csi impliceert ¬nii wegens (2) en vervolgens geeft (5) dat crdyi .
Proof graph: derde versie
We kunnen nu wti 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 wti csi niet mogelijk, dus blijven er 5 over.
Proof graph: derde versie
(neem aan i j)
De fairness van sti en uti 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 sti 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 uti transities fair zijn. Dat kunnen we vermijden door voor wti een complementaire plaats ¬wti in te voeren, en rti maar toe te laten als ¬wti 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 rini voor de request ring.De transities zijn:
srrrststi
ecntecutrtilc
: 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 .