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 .