single pdf file
|
@ -1,3 +1,16 @@
|
|||
#+TITLE: Esercizio Definizioni Matematiche
|
||||
#+AUTHOR: Francesco Mecca
|
||||
#+EMAIL: me@francescomecca.eu
|
||||
#+LANGUAGE: en
|
||||
#+LaTeX_CLASS: article
|
||||
#+LaTeX_HEADER: \linespread{1.25}
|
||||
#+LaTeX_HEADER: \usepackage{pdfpages}
|
||||
#+LaTeX_HEADER: \usepackage{comment}
|
||||
|
||||
#+EXPORT_SELECT_TAGS: export
|
||||
#+EXPORT_EXCLUDE_TAGS: noexport
|
||||
#+OPTIONS: H:2 toc:nil \n:nil @:t ::t |:t ^:{} _:{} *:t TeX:t LaTeX:t
|
||||
#+STARTUP: showall
|
||||
* Insiemi
|
||||
** Numeri naturali
|
||||
|
||||
|
|
|
@ -1,3 +1,16 @@
|
|||
#+TITLE: Esercizio CPN
|
||||
#+AUTHOR: Francesco Mecca
|
||||
#+EMAIL: me@francescomecca.eu
|
||||
#+LANGUAGE: en
|
||||
#+LaTeX_CLASS: article
|
||||
#+LaTeX_HEADER: \linespread{1.25}
|
||||
#+LaTeX_HEADER: \usepackage{pdfpages}
|
||||
#+LaTeX_HEADER: \usepackage{comment}
|
||||
|
||||
#+EXPORT_SELECT_TAGS: export
|
||||
#+EXPORT_EXCLUDE_TAGS: noexport
|
||||
#+OPTIONS: H:2 toc:nil \n:nil @:t ::t |:t ^:{} _:{} *:t TeX:t LaTeX:t
|
||||
#+STARTUP: showall
|
||||
* Rete E
|
||||
|
||||
#+CAPTION: Rete E
|
||||
|
|
|
@ -1,3 +1,16 @@
|
|||
#+TITLE: Esercizio P/N
|
||||
#+AUTHOR: Francesco Mecca
|
||||
#+EMAIL: me@francescomecca.eu
|
||||
#+LANGUAGE: en
|
||||
#+LaTeX_CLASS: article
|
||||
#+LaTeX_HEADER: \linespread{1.25}
|
||||
#+LaTeX_HEADER: \usepackage{pdfpages}
|
||||
#+LaTeX_HEADER: \usepackage{comment}
|
||||
|
||||
#+EXPORT_SELECT_TAGS: export
|
||||
#+EXPORT_EXCLUDE_TAGS: noexport
|
||||
#+OPTIONS: H:2 toc:nil \n:nil @:t ::t |:t ^:{} _:{} *:t TeX:t LaTeX:t
|
||||
#+STARTUP: showall
|
||||
* Rete A
|
||||
M master identici e S slave identici di tipo 1.
|
||||
|
||||
|
@ -6,12 +19,12 @@ M master identici e S slave identici di tipo 1.
|
|||
|
||||
La figura rappresenta la rete di Petri P/T dell'esercizio A. Il master
|
||||
è modellato dai posti M0, M1, M2, M3 e dalle transizioni
|
||||
Azione_Locale, Richiesta_Servizio, Attesa_Elaborazione e Reset_M
|
||||
Lo slave è modellato dai posti S0, S1_a, S1_b, S2_a, S2_b e
|
||||
S3 e dalle transizioni Inizio_Servizio, Azione_Locale_Sa,
|
||||
Azione_Locale_Sb, Fine_Servizio e Reset_S. La richiesta del servizio
|
||||
verso lo slave e` gestita attraverso due buffer, posti Buffer_Input e
|
||||
posto Buffer_Output.
|
||||
/Azione\under{}Locale/, /Richiesta\under{}Servizio/, /Attesa\under{}Elaborazione/ e /Reset\under{}M/
|
||||
Lo slave è modellato dai posti /S0/, /S1_a/, /S1_b/, /S2_a/, /S2_b/ e
|
||||
/S3/ e dalle transizioni /Inizio\under{}Servizio/, /Azione\under{}Locale\under{}S_a/,
|
||||
/Azione\under{}Locale\under{}S_b/, /Fine\under{}Servizio/ e /Reset\under{}S/. La richiesta del servizio
|
||||
verso lo slave e` gestita attraverso due buffer, posti /Buffer\under{}Input/ e
|
||||
posto /Buffer\under{}Output/.
|
||||
|
||||
** Risultati
|
||||
Nella tabella vengono mostrate il numero di archi e di nodi al variare
|
||||
|
@ -52,18 +65,16 @@ Una rete di petri puo` essere ridotta usando le seguendi tecniche:
|
|||
- eliminazione
|
||||
- rimozione dei loop
|
||||
Nelle figure vengono mostrate alcune fasi di riduzione della rete in
|
||||
analisi; in ordine sono stati applicati:
|
||||
- fusione di alcuni posti
|
||||
- fusione di alcune transizioni
|
||||
- eliminazione di alcuni posti
|
||||
- eliminazione di alcune transizioni
|
||||
- riduzione di self loop
|
||||
|
||||
[[./riduzione/fusione1.jpg]]
|
||||
[[./riduzione/fusione2.jpg]]
|
||||
analisi.
|
||||
#+CAPTION: eliminazione di posti identici
|
||||
[[./riduzione/eliminazione1.jpg]]
|
||||
# [[./riduzione/eliminazione2.jpg]]
|
||||
[[./riduzione/rimozione1.jpg]]
|
||||
#+CAPTION: fusione di posti
|
||||
[[./riduzione/fusione1.jpg]]
|
||||
#+CAPTION: fusione di transizioni
|
||||
[[./riduzione/fusione2.jpg]]
|
||||
#+CAPTION: fusione di transizioni e posti
|
||||
[[./riduzione/fusione3.jpg]]
|
||||
\clearpage
|
||||
** P e T invarianti
|
||||
Tramite GreatSPN possiamo calcolare gli T- e P- semiflussi
|
||||
|
||||
|
@ -71,30 +82,29 @@ Tramite GreatSPN possiamo calcolare gli T- e P- semiflussi
|
|||
[[./semiflowsAT.jpg]]
|
||||
#+CAPTION: P-semiflows
|
||||
[[./semiflowsAP.jpg]]
|
||||
\clearpage
|
||||
|
||||
Gli P-semiflussi sono i seguenti:
|
||||
| S0 + S1_a + S2_a + S3
|
||||
| S0 + S1_b + S2_b + S3
|
||||
| M0 + M1 + M2 + M3
|
||||
| S1_a + S2_a + Buffer_output + Buffer_input + M0 + M1 + M3
|
||||
| S1_b + S2_b + Buffer_output + Buffer_input + M0 + M1 + M3
|
||||
| • S0 + S1_{a} + S2_{a} + S3
|
||||
| • S0 + S1_{b} + S2_{b} + S3
|
||||
| • M0 + M1 + M2 + M3
|
||||
| • S1_{a} + S2_{a} + Buffer\under{}output + Buffer\under{}input + M0 + M1 + M3
|
||||
| • S1_{b} + S2_{b} + Buffer\under{}output + Buffer\under{}input + M0 + M1 + M3
|
||||
Il T-semiflusso e` il seguente:
|
||||
\[
|
||||
Inizio_servizio + azione_locale_sa + azione_locale_sb + \\
|
||||
Fine_servizio + Reset_s + azione_locale_m + Richiesta_servizio + \\
|
||||
Attesa_elaborazione + Reset_m + Reset_s
|
||||
\]
|
||||
| • Inizio\under{}servizio + azione\under{}locale\under{}sa + azione\under{}locale\under{}sb +
|
||||
| \space{}\space{} Fine\under{}servizio + azione\under{}locale\under{}m + Richiesta\under{}servizio +
|
||||
| \space\space Attesa\under{}elaborazione + Reset\under{}M + Reset\under{}S
|
||||
e dato che comprende tutte le transizioni, il sistema rispetta la
|
||||
proprieta` di liveness.
|
||||
Dato che la reteA e` interamente coperta dagli P-semiflussi, possiamo
|
||||
affermare che la rete sia bounded.
|
||||
Gli P-semiflussi ci permettono di ricavare i seguenti invarianti
|
||||
lineari relativi ai marking /m/:
|
||||
| m[S0] + m[S1ₐ] + m[S2ₐ] + m[S3] = 1
|
||||
| m[S0] + m[S1_{b}] + m[S2_{b}] + m[S3] = 1
|
||||
| m[M0] + m[M1] + m[M2] + m[M3] = 1
|
||||
| m[S1ₐ] + m[S2ₐ] + m[Buffer_output] + m[Buffer_input] + m[M0] + m[M1] + m[M3] = 1
|
||||
| m[S1_{b}] + m[S2_{b}] + m[Buffer_output] + m[Buffer_input] + m[M0] + m[M1] + m[M3] = 1
|
||||
| • m[S0] + m[S1ₐ] + m[S2ₐ] + m[S3] = 1
|
||||
| • m[S0] + m[S1_{b}] + m[S2_{b}] + m[S3] = 1
|
||||
| • m[M0] + m[M1] + m[M2] + m[M3] = 1
|
||||
| • m[S1ₐ] + m[S2ₐ] + m[Buffer_output] + m[Buffer_input] + m[M0] + m[M1] + m[M3] = 1
|
||||
| • m[S1_{b}] + m[S2_{b}] + m[Buffer_output] + m[Buffer_input] + m[M0] + m[M1] + m[M3] = 1
|
||||
Dato che ∀p ∈ P, m[p] ≥ 0 possiamo affermare, a partire dalle
|
||||
precedenti uguaglianze che:
|
||||
- ogni posto nei seguenti insieme e` in mutua esclusione con gli
|
||||
|
@ -110,24 +120,24 @@ precedenti uguaglianze che:
|
|||
| S1ₐ, S1_{b}, S3, M0, M1, M3
|
||||
e quindi possiamo provare a dimostrare l'assenza di deadlock
|
||||
partendo dagli invarianti lineari relativi ai marking:
|
||||
| m[S0] + m[S2ₐ] = 1
|
||||
| m[S0] + m[S2_{b}] = 1
|
||||
| m[M2] = 1
|
||||
| m[S2ₐ] + m[Buffer_output] + m[Buffer_input] = 1
|
||||
| m[S2_{b}] + m[Buffer_output] + m[Buffer_input] = 1
|
||||
| • m[S0] + m[S2ₐ] = 1
|
||||
| • m[S0] + m[S2_{b}] = 1
|
||||
| • m[M2] = 1
|
||||
| • m[S2ₐ] + m[Buffer_output] + m[Buffer_input] = 1
|
||||
| • m[S2_{b}] + m[Buffer_output] + m[Buffer_input] = 1
|
||||
Dato che M2 e` marcata, per far si` che /attesa_elaborazione/ non
|
||||
venga abilitata:
|
||||
| m[Buffer_output] = 0
|
||||
Inoltre per far si` che /Inizio_Servizio/ e /Fine_Servizio/ non vengano abilitate:
|
||||
| m[Buffer_input] + M[S0] ≤ 1
|
||||
| m[S2ₐ] + m[S2_{b}] ≤ 1
|
||||
Inoltre per far si` che //Inizio\under{}Servizio// e //Fine\under{}Servizio// non vengano abilitate:
|
||||
| • m[Buffer_input] + M[S0] ≤ 1
|
||||
| • m[S2ₐ] + m[S2_{b}] ≤ 1
|
||||
Riassumendo, il sistema e` il seguente:
|
||||
| m[S0] + m[S2ₐ] = 1
|
||||
| m[S0] + m[S2_{b}] = 1
|
||||
| m[S2ₐ] + m[Buffer_input] = 1
|
||||
| m[S2_{b}] + m[Buffer_input] = 1
|
||||
| m[Buffer_input] + M[S0] ≤ 1
|
||||
| m[S2ₐ] + m[S2_{b}] ≤ 1
|
||||
| • m[S0] + m[S2ₐ] = 1
|
||||
| • m[S0] + m[S2_{b}] = 1
|
||||
| • m[S2ₐ] + m[Buffer_input] = 1
|
||||
| • m[S2_{b}] + m[Buffer_input] = 1
|
||||
| • m[Buffer_input] + M[S0] ≤ 1
|
||||
| • m[S2ₐ] + m[S2_{b}] ≤ 1
|
||||
che per la legge di conservazione dei token, non puo` essere
|
||||
soddisfatto. Quindi nel sistema non vi e` la possibilita` di deadlock.
|
||||
|
||||
|
@ -139,19 +149,23 @@ liberamente dai master.
|
|||
[[./reteB.jpg]]
|
||||
|
||||
La figura rappresenta la rete di Petri P/T dell'esercizio B. Il master
|
||||
è modellato dai posti M0, M1, M2, M3 e dalle transizioni
|
||||
Azione_Locale, Richiesta_Servizio, Attesa_Elaborazione e Reset_M
|
||||
Lo slave di tipo 1 è modellato dai posti S0, S1_a, S1_b, S2_a, S2_b e
|
||||
S3 e dalle transizioni Inizio_Servizio, Azione_Locale_Sa,
|
||||
Azione_Locale_Sb, Fine_Servizio e Reset_S.
|
||||
Lo slave di tipo 2 è modellato dai posti R0, R1_a, R1_b, R2_a, R2_b e
|
||||
R3 e dalle transizioni Inizio_Servizio_R, Azione_Locale_R, Fine_Servizio e Reset_R.
|
||||
La richiesta del servizio
|
||||
verso lo slave scelto e` gestita attraverso due buffer, posti
|
||||
FreeChoice e Risultato.
|
||||
è modellato dai posti /M0/, /M1/, /M2/, /M3/ e dalle transizioni
|
||||
/Azione\under{}Locale/, /Richiesta\under{}Servizio/,
|
||||
/Attesa\under{}Elaborazione/ e /Reset\under{}M/ Lo slave di tipo 1 è
|
||||
modellato dai posti /S0/, /S1_a/, /S1_b/, /S2_a/, /S2_b/ e S3 e dalle
|
||||
transizioni /Inizio\under{}Servizio/,
|
||||
/Azione\under{}Locale\under{}S_a/, /Azione\under{}Locale\under{}S_b/,
|
||||
/Fine\under{}Servizio/ e /Reset\under{}S/. Lo slave di tipo 2 è
|
||||
modellato dai posti /R0/, /R1_a/, /R1_b/, /R2_a/, /R2_b/ e /R3/ e dalle
|
||||
transizioni /Inizio\under{}Servizio\under{}R/,
|
||||
/Azione\under{}Locale\under{}R/, /Fine\under{}Servizio/ e /Reset\under{}R/. La
|
||||
richiesta del servizio verso lo slave scelto e` gestita attraverso due
|
||||
buffer, /FreeChoice/ e /Risultato/.
|
||||
\clearpage
|
||||
|
||||
|
||||
** Risultati
|
||||
Al variare del marking del master:
|
||||
| master, slaves | Stati | Archi |
|
||||
|----------------+--------+--------|
|
||||
| 1, 2 | 40 | 76 |
|
||||
|
@ -165,7 +179,7 @@ FreeChoice e Risultato.
|
|||
| 9, 2 | 69784 | 373252 |
|
||||
| 10, 2 | 116116 | 642928 |
|
||||
|
||||
Parametrizzando anche il numero di slaves:
|
||||
Parametrizzando anche il marking sugli slaves (R+S):
|
||||
| master, slaves | Stati | Archi |
|
||||
|----------------+---------+----------|
|
||||
| 1, 2 | 40 | 76 |
|
||||
|
@ -187,25 +201,20 @@ Tramite GreatSPN possiamo calcolare gli T- e P- semiflussi
|
|||
[[./semiflowsBT.jpg]]
|
||||
#+CAPTION: P-semiflows
|
||||
[[./semiflowsBP.jpg]]
|
||||
|
||||
Gli P-invarianti sono i seguenti:
|
||||
| S0 + S1_a + S2_a + S3
|
||||
| S0 + S1_b + S2_b + S3
|
||||
| R0 + R1 + R2 + R3
|
||||
| M0 + M1 + M2 + M3
|
||||
| S1_a + S2_a + R1 + R2 + M0 + M1 + M3 + Freechoice + P0 + P1 + Risultato
|
||||
| S1_b + S2_b + R1 + R2 + M0 + M1 + M3 + Freechoice + P0 + P1 + Risultato
|
||||
| • S0 + S1_a + S2_a + S3
|
||||
| • S0 + S1_b + S2_b + S3
|
||||
| • R0 + R1 + R2 + R3
|
||||
| • M0 + M1 + M2 + M3
|
||||
| • S1_a + S2_a + R1 + R2 + M0 + M1 + M3 + Freechoice + P0 + P1 + Risultato
|
||||
| • S1_b + S2_b + R1 + R2 + M0 + M1 + M3 + Freechoice + P0 + P1 + Risultato
|
||||
Gli T-invarianti sono i seguenti:
|
||||
\[
|
||||
Inizio_servizio_R + azione_locale_R + \\
|
||||
Fine_servizio_R + Reset_R + azione_locale_m + Richiesta_servizio + \\
|
||||
Attesa_elaborazione + Reset_M + Scelta_2
|
||||
\]
|
||||
\[
|
||||
Inizio_servizio_S + azione_locale_sa + azione_locale_sb + \\
|
||||
Fine_servizio_S + Reset_s + azione_locale_m + Richiesta_servizio + \\
|
||||
Attesa_elaborazione + Reset_m + Scelta_1
|
||||
\]
|
||||
| • Inizio\under{}servizio\under{}R + azione\under{}locale\under{}R +
|
||||
| \space\space Fine\under{}servizio\under{}R + Reset\under{}R + azione\under{}locale\under{}m + Richiesta\under{}servizio +
|
||||
| \space\space Attesa\under{}elaborazione + Reset\under{}M + Scelta\under{}2
|
||||
| • Inizio\under{}servizio\under{}S + azione\under{}locale\under{}sa + azione\under{}locale\under{}sb +
|
||||
| \space\space Fine\under{}servizio\under{}S + Reset\under{}s + azione\under{}locale\under{}m + Richiesta\under{}servizio +
|
||||
| \space\space Attesa\under{}elaborazione + Reset\under{}m + Scelta\under{}1
|
||||
Dato che ci sono due semiflussi, ognuno relativo alle transizioni dei
|
||||
due diversi slaves, c'e` possibilita` di starvation.
|
||||
Possiamo infatti immaginare una traccia di esecuzione in cui il master
|
||||
|
@ -218,34 +227,37 @@ In tal caso non avremmo starvation e la proprieta` di liveness sarebbe rispettat
|
|||
Dato che la reteB e` interamente coperta dagli P-semiflussi, possiamo
|
||||
affermare che la rete sia bounded.
|
||||
Dimostriamo invece che la rete non ha possibilita` di deadlock.
|
||||
| m[S0] + m[S1_a] + m[S2_a] + m[S3] = 1
|
||||
| m[S0] + m[S1_{b}] + m[S2_{b}] + m[S3] = 1
|
||||
| m[R0] + m[R1] + m[R2] + m[R3] = 1
|
||||
| m[M0] + m[M1] + m[M2] + m[M3] = 1
|
||||
| m[S1_a] + m[S2_a] + m[R1] + m[R2] + m[M0] + m[M1] + m[M3] + m[Freechoice] + m[P0] + m[P1] + m[Risultato] = 1
|
||||
| m[S1_{b}] + m[S2_{b}] + m[R1] + m[R2] + m[M0] + m[M1] + m[M3] + m[Freechoice] + m[P0] + m[P1] + m[Risultato] = 1
|
||||
| • m[S0] + m[S1_a] + m[S2_a] + m[S3] = 1
|
||||
| • m[S0] + m[S1_{b}] + m[S2_{b}] + m[S3] = 1
|
||||
| • m[R0] + m[R1] + m[R2] + m[R3] = 1
|
||||
| • m[M0] + m[M1] + m[M2] + m[M3] = 1
|
||||
| • m[S1_a] + m[S2_a] + m[R1] + m[R2] + m[M0] + m[M1] +
|
||||
| \space{}\space{} m[M3] + m[Freechoice] + m[P0] + m[P1] + m[Risultato] = 1
|
||||
| • m[S1_{b}] + m[S2_{b}] + m[R1] + m[R2] + m[M0] + m[M1] +
|
||||
| \space{}\space{} m[M3] + m[Freechoice] + m[P0] + m[P1] + m[Risultato] = 1
|
||||
|
||||
I posti che sono gli unici enablers di una sola transizione sono:
|
||||
| M0, M1, M3, R1, R2, R3, FreeChoice, S1ₐ, S1_{b}, S3
|
||||
Gli invarianti lineari dei marking diventano:
|
||||
| m[S0] + m[S2_a] = 1
|
||||
| m[S0] + m[S2_{b}] = 1
|
||||
| m[R0] = 1
|
||||
| m[M2] = 1
|
||||
| m[S2_a] + m[P0] + m[P1] + m[Risultato] = 1
|
||||
| m[S2_{b}] m[P0] + m[P1] + m[Risultato] = 1
|
||||
Dati i marking in R0 e M2, per far si` che /Inizio_Servizio_R/,
|
||||
/Attesa_Elaborazione/, /Fine_Servizioₛ/ e /Inizio_Servizioₛ/ non vengano abilitati:
|
||||
| m[P0] = 0
|
||||
| m[Risultato] = 0
|
||||
| m[S2ₐ] + m[S2_{b}] ≤ 1
|
||||
| m[P1] + m[S0] ≤ 1
|
||||
| • m[S0] + m[S2_a] = 1
|
||||
| • m[S0] + m[S2_{b}] = 1
|
||||
| • m[R0] = 1
|
||||
| • m[M2] = 1
|
||||
| • m[S2_a] + m[P0] + m[P1] + m[Risultato] = 1
|
||||
| • m[S2_{b}] m[P0] + m[P1] + m[Risultato] = 1
|
||||
Dati i marking in R0 e M2, per far si` che //Inizio\under{}Servizio/_R/,
|
||||
//Attesa\under{}Elaborazione//, //Fine\under{}Servizio/ₛ/ e //Inizio\under{}Servizio/ₛ/ non vengano abilitati:
|
||||
| • m[P0] = 0
|
||||
| • m[Risultato] = 0
|
||||
| • m[S2ₐ] + m[S2_{b}] ≤ 1
|
||||
| • m[P1] + m[S0] ≤ 1
|
||||
Il sistema si riduce a:
|
||||
| m[S0] + m[S2_a]= 1
|
||||
| m[S0] + m[S2_{b}] = 1
|
||||
| m[S2_a] + m[P1] = 1
|
||||
| m[S2_{b}] + m[P1] = 1
|
||||
| m[S2ₐ] + m[S2_{b}] ≤ 1
|
||||
| m[P1] + m[S0] ≤ 1
|
||||
| • m[S0] + m[S2_a]= 1
|
||||
| • m[S0] + m[S2_{b}] = 1
|
||||
| • m[S2_a] + m[P1] = 1
|
||||
| • m[S2_{b}] + m[P1] = 1
|
||||
| • m[S2ₐ] + m[S2_{b}] ≤ 1
|
||||
| • m[P1] + m[S0] ≤ 1
|
||||
che non puo` essere soddisfatto per la legge di conservazione dei token.
|
||||
|
||||
* Rete C
|
||||
|
@ -257,13 +269,13 @@ liberamente dai master.
|
|||
|
||||
La figura rappresenta la rete di Petri P/T dell'esercizio C. Il master
|
||||
è modellato dai posti M0, M1, M2, M3 e dalle transizioni
|
||||
Azione_Locale, Richiesta_Servizio, Attesa_Elaborazione e Reset_M
|
||||
Azione_Locale, /Richiesta\under{}Servizio/, /Attesa\under{}Elaborazione/ e /Reset\under{}M/
|
||||
Lo slave di tipo 1 è modellato dai posti S0, S1_a, S1_b, S2_a, S2_b e
|
||||
S3 e dalle transizioni Inizio_Servizio, Azione_Locale_Sa,
|
||||
Azione_Locale_Sb, Fine_Servizio e Reset_S (il secondo master e` una
|
||||
S3 e dalle transizioni /Inizio\under{}Servizio/, /Azione\under{}Locale\under{}S_a/,
|
||||
/Azione\under{}Locale\under{}S_b/, /Fine\under{}Servizio/ e /Reset\under{}S/ (il secondo master e` una
|
||||
copia del primo).
|
||||
Lo slave di tipo 2 è modellato dai posti R0, R1_a, R1_b, R2_a, R2_b e
|
||||
R3 e dalle transizioni Inizio_Servizio_R, Azione_Locale_R, Fine_Servizio e Reset_R.
|
||||
R3 e dalle transizioni /Inizio\under{}Servizio/_R, Azione_Locale_R, /Fine\under{}Servizio/ e Reset_R.
|
||||
La richiesta del servizio
|
||||
verso lo slave scelto e` gestita attraverso due buffer, posti
|
||||
FreeChoice e Risultato.
|
||||
|
@ -289,56 +301,54 @@ Dato che la reteC e` interamente coperta dagli P-semiflussi, possiamo
|
|||
affermare che la rete sia bounded.
|
||||
Gli P-semiflussi ci permettono di ricavare i seguenti invarianti
|
||||
lineari relativi ai marking /m/:
|
||||
| m[S0] + m[S1ₐ] + m[S2ₐ] + m[S3] = 1
|
||||
| m[S0] + m[S1_{b}] + m[S2_{b}] + m[S3] = 1
|
||||
| m[R0] + m[R1] + m[R2] + m[R3] = 1
|
||||
| m[M0] + m[M1] + m[M2] + m[M3] = 1
|
||||
| m[copy_M0] + m[copy_M1] + m[copy_M2] + m[copy_M3] = 1
|
||||
\[
|
||||
m[S1ₐ] + m[S2ₐ] + m[R1] + m[R2] + m[M0] + m[M1] + m[M3] + m[Freechoice] + m[P0] + m[P1] +
|
||||
m[Risultato] + m[copy_M0] + m[copy_M1] + m[copy_M3] = 1
|
||||
\]
|
||||
\[
|
||||
m[S1_{b}] + m[S2_{b}] + m[R1] + m[R2] + m[M0] + m[M1] + m[M3] + m[Freechoice] + m[P0] + m[P1] +
|
||||
m[Risultato] + m[copy_M0] + m[copy_M1] + m[copy_M3] = 1
|
||||
\]
|
||||
| • m[S0] + m[S1ₐ] + m[S2ₐ] + m[S3] = 1
|
||||
| • m[S0] + m[S1_{b}] + m[S2_{b}] + m[S3] = 1
|
||||
| • m[R0] + m[R1] + m[R2] + m[R3] = 1
|
||||
| • m[M0] + m[M1] + m[M2] + m[M3] = 1
|
||||
| • m[copy_M0] + m[copy_M1] + m[copy_M2] + m[copy_M3] = 1
|
||||
| • m[S1ₐ] + m[S2ₐ] + m[R1] + m[R2] + m[M0] +
|
||||
| \space\space m[M1] + m[M3] + m[Freechoice] + m[P0] + m[P1] +
|
||||
| \space\space m[Risultato] + m[copy_M0] + m[copy_M1] + m[copy_M3] = 1
|
||||
| • m[S1_{b}] + m[S2_{b}] + m[R1] + m[R2] + m[M0] +
|
||||
| \space\space m[M1] + m[M3] + m[Freechoice] + m[P0] + m[P1] +
|
||||
| \space\space m[Risultato] + m[copy_M0] + m[copy_M1] + m[copy_M3] = 1
|
||||
Gli spazi /enablers/ di una sola transizione sono i seguenti:
|
||||
| R1, R2, R3, S1ₐ, S1_{b}, S3, Risultato, M0, M1, M3, copy_M0, copy_M1, copy_M3, FreeChoice
|
||||
il sistema precedente diventa:
|
||||
| m[S0] + m[S2ₐ] = 1
|
||||
| m[S0] + m[S2_{b}] = 1
|
||||
| m[R0] = 1
|
||||
| m[M2] = 1
|
||||
| m[copy_M2] = 1
|
||||
| m[S2_{b}] + m[P0] + m[P1] = 1
|
||||
| m[S2_{a}] + m[P0] + m[P1] = 1
|
||||
Dati i marking in R0 e M2 e copy_M2, per far si` che /Inizio_Servizio_R/,
|
||||
/Attesa_Elaborazione/, /copy_Attesa_Elaborazione/, /Fine_Servizioₛ/ e /Inizio_Servizioₛ/ non vengano abilitati:
|
||||
| m[P0] = 0
|
||||
| m[Risultato] = 0
|
||||
| m[S2ₐ] + m[S2_{b}] ≤ 1
|
||||
| m[P1] + m[S0] ≤ 1
|
||||
| • m[S0] + m[S2ₐ] = 1
|
||||
| • m[S0] + m[S2_{b}] = 1
|
||||
| • m[R0] = 1
|
||||
| • m[M2] = 1
|
||||
| • m[copy_M2] = 1
|
||||
| • m[S2_{b}] + m[P0] + m[P1] = 1
|
||||
| • m[S2_{a}] + m[P0] + m[P1] = 1
|
||||
Dati i marking in R0 e M2 e copy_M2, per far si` che //Inizio\under{}Servizio/_R/,
|
||||
//Attesa\under{}Elaborazione//, /copy_/Attesa\under{}Elaborazione//, //Fine\under{}Servizio/ₛ/ e //Inizio\under{}Servizio/ₛ/ non vengano abilitati:
|
||||
| • m[P0] = 0
|
||||
| • m[Risultato] = 0
|
||||
| • m[S2ₐ] + m[S2_{b}] ≤ 1
|
||||
| • m[P1] + m[S0] ≤ 1
|
||||
Il sistema si riduce allo stesso della precedente rete B:
|
||||
| m[S0] + m[S2ₐ] = 1
|
||||
| m[S0] + m[S2_{b}] = 1
|
||||
| m[S2_{b}] + m[P1] = 1
|
||||
| m[S2_{a}] + m[P1] = 1
|
||||
| m[S2ₐ] + m[S2_{b}] ≤ 1
|
||||
| m[P1] + m[S0] ≤ 1
|
||||
| • m[S0] + m[S2ₐ] = 1
|
||||
| • m[S0] + m[S2_{b}] = 1
|
||||
| • m[S2_{b}] + m[P1] = 1
|
||||
| • m[S2_{a}] + m[P1] = 1
|
||||
| • m[S2ₐ] + m[S2_{b}] ≤ 1
|
||||
| • m[P1] + m[S0] ≤ 1
|
||||
e non puo` essere soddisfatto per la legge di conservazione dei token.
|
||||
|
||||
Gli T-invarianti sono i seguenti:
|
||||
- Inizio_Servizioᵣ + Azione_Locale + Fine_Servizioᵣ + T3 +
|
||||
azione_localeₘ + Richiesta_Servizio + Attesa_Elaborazione + Reset_M + Scelta₁
|
||||
- Inizio_Servizioₛ + Azione_Locale_{sa} + Azione_Locale_{sb} + Fine_Servizioₛ + T3 +
|
||||
azione_localeₘ + Richiesta_Servizio + Attesa_Elaborazione +
|
||||
Reset_M + Scelta₁
|
||||
- Inizio_Servizioᵣ + Azione_Locale + Fine_Servizioᵣ + T3 + Scelta₂ +
|
||||
copyₐzione_localeₘ + copy_Richiesta_Servizio +
|
||||
copy_Attesa_Elaborazione + copy_Resetₘ
|
||||
- Inizio_Servizioₛ + Azione_Locale_{sa} + Azione_Locale_{sb} +
|
||||
Fine_Servizioₛ + Reset + Scelta₁ + copy_azione_localeₘ +
|
||||
copy_Richiesta_Servizio + copy_Attesa_Elaborazione + copy_Resetₘ
|
||||
- Inizio\under{}Servizioᵣ + Azione\under{}Locale + Fine\under{}Servizioᵣ + T3 +
|
||||
azione\under{}localeₘ + Richiesta\under{}Servizio + Attesa\under{}Elaborazione + Reset\under{}M + Scelta₁
|
||||
- Inizio\under{}Servizioₛ + Azione\under{}Locale_{sa} + Azione\under{}Locale_{sb} + Fine\under{}Servizioₛ + T3 +
|
||||
azione\under{}localeₘ + Richiesta\under{}Servizio + Attesa\under{}Elaborazione +
|
||||
Reset\under{}M + Scelta₁
|
||||
- Inizio\under{}Servizioᵣ + Azione\under{}Locale + Fine\under{}Servizioᵣ + T3 + Scelta₂ +
|
||||
copyₐzione\under{}localeₘ + copy\under{}Richiesta\under{}Servizio +
|
||||
copy\under{}Attesa\under{}Elaborazione + copy\under{}Resetₘ
|
||||
- Inizio\under{}Servizioₛ + Azione\under{}Locale_{sa} + Azione\under{}Locale_{sb} +
|
||||
Fine\under{}Servizioₛ + Reset + Scelta₁ + copy\under{}azione\under{}localeₘ +
|
||||
copy\under{}Richiesta\under{}Servizio + copy\under{}Attesa\under{}Elaborazione + copy\under{}Resetₘ
|
||||
Come nella rete B, in assenza di fairness non possiamo rispettare la
|
||||
condizione di liveness e c'e` possibilita` di starvation.
|
||||
|
||||
|
@ -356,16 +366,17 @@ Tramite GreatSPN possiamo calcolare gli T- e P- semiflussi
|
|||
[[./semiflowsDT.jpg]]
|
||||
#+CAPTION: P-semiflows
|
||||
[[./semiflowsDP.jpg]]
|
||||
\clearpage
|
||||
|
||||
Gli P-invarianti sono i seguenti:
|
||||
- S0 + S1ₐ + S2ₐ + S3
|
||||
- S0 + S1_{b} + S2_{b} + S3
|
||||
- R0 + R1 + R2 + R3
|
||||
- M0 + M1 + M2 + M3
|
||||
- S1ₐ + S2ₐ + M0 + M1 + M3 + Bufferₛ + Risultato
|
||||
- S1_{b} + S2_{b} + M0 + M1 + M3 + Bufferₛ + Risultato
|
||||
- M0₂ + M1₂ + M3₂
|
||||
- R1 + R2 + M0₂ + M1₂ + M3₂ + Buffer₂ + Risultato₂
|
||||
| • S0 + S1ₐ + S2ₐ + S3
|
||||
| • S0 + S1_{b} + S2_{b} + S3
|
||||
| • R0 + R1 + R2 + R3
|
||||
| • M0 + M1 + M2 + M3
|
||||
| • S1ₐ + S2ₐ + M0 + M1 + M3 + Bufferₛ + Risultato
|
||||
| • S1_{b} + S2_{b} + M0 + M1 + M3 + Bufferₛ + Risultato
|
||||
| • M0₂ + M1₂ + M3₂
|
||||
| • R1 + R2 + M0₂ + M1₂ + M3₂ + Buffer₂ + Risultato₂
|
||||
Ai fini della dimostrazione dell'assenza di deadlock, possiamo notare
|
||||
che lo slave di tipo 2 e` equivalente allo slave di tipo 1 se
|
||||
si applicano due riduzioni alla rete (vengono fusi in un unico posto
|
||||
|
@ -373,11 +384,11 @@ S1ₐ-S2ₐ e S1_{b}-S2_{b}, poi eliminata la fork).
|
|||
Inoltre i master sono indipendenti fra di loro e ciascuno rispetta l'assenza
|
||||
di deadlock come gia` dimostrato nella rete A.
|
||||
Gli T-invarianti sono i seguenti:
|
||||
- Inizio_Servizioₛ + azione_locale_{sa} + azione_locale_{sb} +
|
||||
Fine_Servizioₛ + Reset + azione_localeₘ + Richiesta_Servizio +
|
||||
Attesa_Elaborazione + Resetₘ
|
||||
- Inizio_Servizioᵣ + Azione_locale + Fine_Servizioᵣ + T3
|
||||
azione_locale_{m2} + Richiesta_Servizio₂ + Attesa_Elaborazione₂ +
|
||||
- Inizio\under{}Servizioₛ + azione_locale_{sa} + azione_locale_{sb} +
|
||||
Fine\under{}Servizioₛ + Reset + azione_localeₘ + Richiesta\under{}Servizio +
|
||||
Attesa\under{}Elaborazione + Resetₘ
|
||||
- Inizio\under{}Servizioᵣ + Azione\under{}locale + Fine\under{}Servizioᵣ + T3
|
||||
azione\under{}locale_{m2} + Richiesta\under{}Servizio₂ + Attesa\under{}Elaborazione₂ +
|
||||
Reset_{m2}
|
||||
Come nella rete B, in assenza di fairness non possiamo rispettare la
|
||||
condizione di liveness e c'e` possibilita` di starvation.
|
||||
|
@ -389,7 +400,7 @@ Di seguito vengono mostrati i decision diagram usando per le
|
|||
assegnazioni i seguenti algoritmi:
|
||||
- Sloan: un algoritmo di riduzione della banda di matrici sparse con
|
||||
una buona performance
|
||||
- (advanced) Cuthill-McKee: un altro algoritmo di riduzione della banda di
|
||||
- Cuthill-McKee: un altro algoritmo di riduzione della banda di
|
||||
matrici sparse
|
||||
- Tovchigrechko e Noack: due algoritmo appositamente ideati per le reti
|
||||
di Petri, anch'essi con una buona performance
|
||||
|
@ -400,16 +411,16 @@ assegnazioni i seguenti algoritmi:
|
|||
in analisi ha restituito il risultato peggiore
|
||||
|
||||
#+CAPTION: Algoritmo di Sloan
|
||||
[[./diagrammi/sloan.jpg]]
|
||||
\includepdf{./diagrammi/sloan.png}
|
||||
#+CAPTION: Algoritmo di Cuthull-McKee
|
||||
[[./diagrammi/mckee.jpg]]
|
||||
\includepdf{./diagrammi/mckee.png}
|
||||
#+CAPTION: Algoritmo di Tovchigrechko
|
||||
[[./diagrammi/tovchi.jpg]]
|
||||
\includepdf{./diagrammi/tovchi.png}
|
||||
#+CAPTION: Algoritmo di Noack
|
||||
[[./diagrammi/noack.jpg]]
|
||||
\includepdf{./diagrammi/noack.png}
|
||||
#+CAPTION: Algoritmo P-Chain
|
||||
[[./diagrammi/p-chain.jpg]]
|
||||
\includepdf{./diagrammi/p-chain.png}
|
||||
#+CAPTION: Algoritmo Gradient-P
|
||||
[[./diagrammi/gradient.jpg]]
|
||||
\includepdf{./diagrammi/gradient.png}
|
||||
#+CAPTION: Algoritmo di Gibbs-Poole-Stockmeier
|
||||
[[./diagrammi/gibbs.jpg]]
|
||||
\includepdf{./diagrammi/gibbs.png}
|
||||
|
|
BIN
anno3/vpc/consegne/2/diagrammi/gibbs.png
Normal file
After Width: | Height: | Size: 206 KiB |
BIN
anno3/vpc/consegne/2/diagrammi/gradient.png
Normal file
After Width: | Height: | Size: 124 KiB |
BIN
anno3/vpc/consegne/2/diagrammi/mckee.png
Normal file
After Width: | Height: | Size: 125 KiB |
BIN
anno3/vpc/consegne/2/diagrammi/noack.png
Normal file
After Width: | Height: | Size: 123 KiB |
BIN
anno3/vpc/consegne/2/diagrammi/p-chain.png
Normal file
After Width: | Height: | Size: 125 KiB |
BIN
anno3/vpc/consegne/2/diagrammi/sloan.png
Normal file
After Width: | Height: | Size: 128 KiB |
BIN
anno3/vpc/consegne/2/diagrammi/tovchi.png
Normal file
After Width: | Height: | Size: 123 KiB |
Before Width: | Height: | Size: 43 KiB After Width: | Height: | Size: 58 KiB |
Before Width: | Height: | Size: 16 KiB After Width: | Height: | Size: 38 KiB |
Before Width: | Height: | Size: 29 KiB After Width: | Height: | Size: 41 KiB |
Before Width: | Height: | Size: 24 KiB After Width: | Height: | Size: 35 KiB |
BIN
anno3/vpc/consegne/2/riduzione/fusione3.jpg
Normal file
After Width: | Height: | Size: 22 KiB |
Before Width: | Height: | Size: 4.5 KiB |
|
@ -1,3 +1,10 @@
|
|||
#+TITLE: Esercizio di analisi degli algoritmi di mutua esclusione
|
||||
#+AUTHOR: Francesco Mecca
|
||||
#+EMAIL: me@francescomecca.eu
|
||||
#+LANGUAGE: en
|
||||
#+LaTeX_CLASS: article
|
||||
#+LaTeX_HEADER: \linespread{1.25}
|
||||
#+LaTeX_HEADER: \usepackage{pdfpages}
|
||||
#+LaTeX_HEADER: \usepackage{comment}
|
||||
#+LaTeX_HEADER: \usepackage{regexpatch,fancyvrb,xparse}
|
||||
#+LaTeX_HEADER: \makeatletter
|
||||
|
@ -18,6 +25,11 @@
|
|||
#+LaTeX_HEADER: breaklines=true
|
||||
#+LaTeX_HEADER: }
|
||||
|
||||
#+EXPORT_SELECT_TAGS: export
|
||||
#+EXPORT_EXCLUDE_TAGS: noexport
|
||||
#+OPTIONS: H:2 toc:nil \n:nil @:t ::t |:t ^:{} _:{} *:t TeX:t LaTeX:t
|
||||
#+STARTUP: showall
|
||||
|
||||
\begin{comment}
|
||||
NOTA: nel caso di Ampararore, la formula:
|
||||
| AG(EF(critical_P == 1))
|
||||
|
@ -106,6 +118,7 @@ processi CSP.
|
|||
| Q₂ ::= is_{q}.Q₃
|
||||
| Q₃ ::= critical_{q}.Q₄
|
||||
| Q₄ ::= set_{p}.Q₁
|
||||
Seguono il Reachability Graph costruito con GreatSPN e il Derivation Graph.
|
||||
|
||||
#+CAPTION: Reachability Graph 3.2
|
||||
\includepdf{rg_3.2.jpg}
|
||||
|
@ -224,7 +237,7 @@ processi un'enumerazione di due stati e un contatore di turni intero
|
|||
\hrulefill
|
||||
\lstinputlisting[breaklines]{3.5.smv}
|
||||
\hrulefill
|
||||
|
||||
\clearpage
|
||||
** GreatSPN
|
||||
Il codice utilizzato per le proprieta` CTL e` il seguente:
|
||||
#+BEGIN_SRC
|
||||
|
@ -233,7 +246,7 @@ AG ((#Wait_P==1 || #Await_Q == 1) -> AF (#Done_P == 1 || #Done_Q == 1)) = false
|
|||
AG (#Await_P==1 -> AF (#Done_P == 1)) = false
|
||||
#+END_SRC
|
||||
#+CAPTION: Rete 3.5
|
||||
\includepdf{3.5.jpg}
|
||||
[[./3.5.jpg]]
|
||||
|
||||
** Risultati
|
||||
Nella tabella mostriamo i risultati ottenuti
|
||||
|
@ -350,6 +363,7 @@ nodi ed e` equivalente al Reachability Graph.
|
|||
| Q₃ ::= setTrue_{q}.Q₄
|
||||
| Q₄ ::= critical_{q}.Q₅
|
||||
| Q₅ ::= setFalse_{q}.Q₁
|
||||
Seguono il Reachability Graph costruito con GreatSPN e il Derivation Graph.
|
||||
|
||||
|
||||
#+CAPTION: Reachability Graph 3.6
|
||||
|
@ -423,8 +437,8 @@ risulta rispettata.
|
|||
Ancora meglio, piuttosto che rimuovere una transizione possibile,
|
||||
possiamo restringere la verifica dell'assenza di deadlock alla
|
||||
seguente formula CTL
|
||||
| AG (wₚ → EF (cₚ || c_{q}))
|
||||
| AG(#await_P == 1 -> EF(#critical_Q==1 || #critical_P == 1))
|
||||
| AG (wₚ → EF (cₚ \vert{}\vert{} c_{q}))
|
||||
| AG(#await_P\space== 1 -> EF(#critical_Q==1 \vert{}\vert{} #critical_P == 1))
|
||||
che risulta rispettata.
|
||||
L'assenza di starvation individuale non e` rispettata ne` in NuSmv ne` in
|
||||
GreatSPN in quanto e` possibile che uno dei due processi continui ad
|
||||
|
@ -491,9 +505,11 @@ while true:
|
|||
#+END_SRC
|
||||
** NuSMV
|
||||
Si e` deciso di modellare l'algoritmo allo stesso modo del precedente.
|
||||
|
||||
\hrulefill
|
||||
\lstinputlisting[breaklines]{3.8.smv}
|
||||
\hrulefill
|
||||
\clearpage
|
||||
** GreatSPN
|
||||
Il codice utilizzato per le proprieta` CTL e` il seguente:
|
||||
#+BEGIN_SRC
|
||||
|
@ -509,7 +525,7 @@ AG(#await_P == 1 -> EF(#critical_Q==1 || #critical_P == 1))
|
|||
#+END_SRC
|
||||
che conferma la presenza di deadlock causata dalle due variabili booleane.
|
||||
#+CAPTION: Rete 3.8
|
||||
\includepdf{3.8.jpg}
|
||||
[[./3.8.jpg]]
|
||||
** Risultati
|
||||
Nella tabella mostriamo i risultati ottenuti
|
||||
| | NuSMV | GreatSPN |
|
||||
|
@ -926,13 +942,13 @@ Ci aspettiamo che come in precedenza ci sia deadlock perche` viene
|
|||
data ai processi la possibilita` di rimanere su /local/.
|
||||
Forzando i processi a fare del progresso dallo stato
|
||||
/local/, allora la formula CTL
|
||||
| AG((lₚ || l_{q}) → AF(cₚ∨c_{q})
|
||||
| AG((lₚ \vert{}\vert{} l_{q}) → AF(cₚ∨c_{q})
|
||||
risulta rispettata.
|
||||
Ancora meglio, piuttosto che rimuovere una transizione possibile,
|
||||
possiamo restringere la verifica dell'assenza di deadlock alla
|
||||
seguente formula CTL
|
||||
| AG (wₚ → EF (cₚ || c_{q}))
|
||||
| AG(#await_P == 1 -> EF(#critical_Q==1 || #critical_P == 1))
|
||||
| AG (wₚ → EF (cₚ \vert{}\vert{} c_{q}))
|
||||
| AG(#await_P\space== 1 -> EF(#critical_Q==1 \vert{}\vert{} #critical_P == 1))
|
||||
che risulta rispettata.
|
||||
|
||||
C'e` possibilita` di starvation individuale perche` a differenza di
|
||||
|
|
|
@ -1,5 +1,16 @@
|
|||
#+TITLE: Esercizio Timed Automata
|
||||
#+AUTHOR: Francesco Mecca
|
||||
#+EMAIL: me@francescomecca.eu
|
||||
#+LANGUAGE: en
|
||||
#+LaTeX_CLASS: article
|
||||
#+LaTeX_HEADER: \linespread{1.25}
|
||||
#+LaTeX_HEADER: \usepackage{pdfpages}
|
||||
#+LaTeX_HEADER: \usepackage{comment}
|
||||
|
||||
#+EXPORT_SELECT_TAGS: export
|
||||
#+EXPORT_EXCLUDE_TAGS: noexport
|
||||
#+OPTIONS: H:2 toc:nil \n:nil @:t ::t |:t ^:{} _:{} *:t TeX:t LaTeX:t
|
||||
#+STARTUP: showall
|
||||
* Modello A
|
||||
Sono stati usati tre template per rappresentare un sender, un link wd
|
||||
un receiver
|
||||
|
@ -11,8 +22,8 @@ un receiver
|
|||
Lo stato iniziale dell'automata e` /wait/ che simula l'attesa
|
||||
dell'arrivo di un pacchetto che viene processato nell'intervallo [1;2]
|
||||
del clock /sc/.
|
||||
Lo stato successivo e` /send_pkg/ che invia il pacchetto sul canale di
|
||||
sincronizzazione urgente /ML/. Il sender passa allo stato /wait_ack/
|
||||
Lo stato successivo e` /send\under{}pkg/ che invia il pacchetto sul canale di
|
||||
sincronizzazione urgente /ML/. Il sender passa allo stato /wait\under{}ack/
|
||||
che simula l'attesa di un pacchetto sul canale di sincronizzazione
|
||||
urgente /LM/ e resetta il clock /sc/.
|
||||
Viene simulata la verifica dell'ack in un intervallo di tempo [2;4] e
|
||||
|
@ -24,9 +35,9 @@ successivamente l'automa torna allo stato iniziale resettando il clock
|
|||
Il receiver e` simmetrico al sender. Dallo stato iniziale di /wait/
|
||||
viene simulato l'arrivo di un pacchetto sul canale di sincronizzazione
|
||||
urgente /LR/ che permette al receiver di resettare il clock /rc/ e
|
||||
avanzare nello stato /recv_pkg/, simulando la preparazione del
|
||||
avanzare nello stato /recv\under{}pkg/, simulando la preparazione del
|
||||
pacchetto in un intervallo di tempo [2;4].
|
||||
La transizione dallo stato /done_pkg/ a /send_ack/ simula la generazione
|
||||
La transizione dallo stato /done\under{}pkg/ a /send\under{}ack/ simula la generazione
|
||||
di un pacchetto di ack in un intervallo di tempo [2;4] ed tornare allo
|
||||
stato iniziale dopo aver inviato il pacchetto nel canale di
|
||||
sincronizzazione urgente /RL/.
|
||||
|
@ -35,12 +46,12 @@ sincronizzazione urgente /RL/.
|
|||
** Link
|
||||
Il link e` modellato come un canale perfetto senza perdite. Lo stato
|
||||
interno /idle/ simula l'attesa di un pacchetto da parte del receiver o
|
||||
del sender. Lo stato /received_pkg/ simula l'arrivo di un pacchetto da
|
||||
del sender. Lo stato /received\under{}pkg/ simula l'arrivo di un pacchetto da
|
||||
parte del sender sul canale /ML/ che viene processato e spedito al
|
||||
receiver sul canale /LR/. Simmetricamente le stesse operazioni di
|
||||
attesa, processing e invio avvengono con i pacchetti di ack di cui si
|
||||
simula l'arrivo nello stato /received_ack/ dal canale di trasmissione
|
||||
/RL/ e l'invio verso il sender dallo stato /resend_ack/ attraverso il
|
||||
simula l'arrivo nello stato /received\under{}ack/ dal canale di trasmissione
|
||||
/RL/ e l'invio verso il sender dallo stato /resend\under{}ack/ attraverso il
|
||||
canale di trasmissione /LM/. Per il processing dei pacchetti
|
||||
l'intervallo di tempo e` sempre [2;4].
|
||||
#+CAPTION: Link protocollo A
|
||||
|
@ -51,12 +62,12 @@ Sono state verificate tre proprieta` TCTL sul modello:
|
|||
| A[] (not deadlock)
|
||||
che viene rispettata e indica che la traccia del sistema e` infinita
|
||||
- Il sender ricevera` sempre un ack
|
||||
| AF sender.received_ack
|
||||
| A<> sender.received_ack
|
||||
| AF sender.received\under{}ack
|
||||
| A<> sender.received\under{}ack
|
||||
la proprieta` risulta vera in quanto il link non ha perdite.
|
||||
- Il receiver ricevera` sempre un pacchetto
|
||||
| AF receiver.recv_pkg
|
||||
| A<> receiver.recv_pkg
|
||||
| AF receiver.recv\under{}pkg
|
||||
| A<> receiver.recv\under{}pkg
|
||||
e` una proprieta` rispettata in quando non ci sono constraint sul
|
||||
tempo di attesa del pacchetto.
|
||||
** Tempo attesa
|
||||
|
@ -71,14 +82,14 @@ la possibilita` di perdita o corruzione di un pacchetto.
|
|||
** Link
|
||||
Come si denota dall'immagine il link e` simile a quello del modello A
|
||||
eccezion fatta per la possibilita` di procedere non
|
||||
deterministicamente dagli spazi /received_pkg/ e /received_ack/ verso
|
||||
deterministicamente dagli spazi /received\under{}pkg/ e /received\under{}ack/ verso
|
||||
/loss/
|
||||
#+CAPTION: Link protocollo B
|
||||
[[./link_B.jpg]]
|
||||
Mostriamo un trace in cui il link perde un pacchetto di ack inviato
|
||||
dal sender e il sistema va in deadlock.
|
||||
Dalla figura possiamo notare la transizione che simula la perdita,
|
||||
ovvero l'arco /received_ack/ → /loss/.
|
||||
ovvero l'arco /received\under{}ack/ → /loss/.
|
||||
#+CAPTION: Trace con deadlock
|
||||
[[./trace_B.jpg]]
|
||||
\includepdf{trace_B2.jpg}
|
||||
|
@ -88,15 +99,15 @@ Sono state verificate quattro proprieta` TCTL sul modello:
|
|||
| A[] (not deadlock)
|
||||
che non e` rispettata
|
||||
- Il sender compiera` sempre del progresso
|
||||
| sender.waitACK –> (sender.receivedACK)
|
||||
| sender.wait_ack --> (sender.received_ack)
|
||||
la proprieta` non risulta vera in quanto il link ha perdite
|
||||
- Il receiver ricevera` sempre un pacchetto
|
||||
| AF receiver.recv_pkg
|
||||
| A<> receiver.recv_pkg
|
||||
| AF receiver.recv\under{}pkg
|
||||
| A<> receiver.recv\under{}pkg
|
||||
che come per la proprieta` precedente non puo` risultare vera
|
||||
- Il receiver puo` ricevere un pacchetto
|
||||
| EF receiver.recv_pkg
|
||||
| E<> receiver.recv_pkg
|
||||
| EF receiver.recv\under{}pkg
|
||||
| E<> receiver.recv\under{}pkg
|
||||
la proprieta` risulta vera perche` il link in alcuni path riesce ad
|
||||
inviare il pacchetto (non avvengono perdite sul canale)
|
||||
** Tempo attesa
|
||||
|
@ -114,7 +125,7 @@ tenere traccia dei pacchetti inviati e degli ack ricevuti.
|
|||
|
||||
** Receiver
|
||||
Di seguito viene mostrato il receiver del modello C. Rispetto al
|
||||
Modello B il receiver utilizza una flag binaria locale /r_frame/ per tenere
|
||||
Modello B il receiver utilizza una flag binaria locale /r\under{}frame/ per tenere
|
||||
traccia degli pacchetti gia` ricevuti e processati.
|
||||
#+CAPTION: Receiver protocollo C
|
||||
[[./receiver_C.jpg]]
|
||||
|
@ -124,7 +135,7 @@ escludendo per lo stato iniziale, in modo da poter processare nella
|
|||
parte destra i frame di tipo 0 e nella parte sinistra i frame di
|
||||
tipo 1.
|
||||
Inoltre sono stati aggiunti due timer che, nel momento in cui
|
||||
l'automa e` fermo su /wait_ack/ allo scadere del timeout, permettono
|
||||
l'automa e` fermo su /wait\under{}ack/ allo scadere del timeout, permettono
|
||||
di spostarsi nello spazio /lost/ e riprovare l'invio del pacchetto.
|
||||
Si nota subito che i due timer sono indipendenti l'uno dall'altro e vi
|
||||
e` la possibilita` di modellare i sender senza duplicare il numero di
|
||||
|
@ -139,37 +150,37 @@ maggiore del piu` grande fra i seguenti valore:
|
|||
- il massimo tempo necessario all'invio di un pacchetto che il sender ha gia`
|
||||
processato
|
||||
Se non si rispetta questo constraint il sistema va in deadlock.
|
||||
Nel modello utilizzato lo spazio /is_dup/ e /done_pkg/ del receiver
|
||||
Nel modello utilizzato lo spazio /is\under{}dup/ e /done\under{}pkg/ del receiver
|
||||
hanno lo stesso invariante e il timeout /TOUT/ ha valore minimo 16.
|
||||
\begin{comment}
|
||||
Ho calcolato il timeout considerando i seguenti cammini
|
||||
# Perdita per sender
|
||||
Link: received_pkg -> resend_pkg = 4
|
||||
Receiver: recv_pkg -> done_pkg = 4
|
||||
Receiver: done_pkg -> send_ack = 4
|
||||
Link: received_ack -> resend_ack = 4
|
||||
Link: received\under{}pkg -> resend\under{}pkg = 4
|
||||
Receiver: recv\under{}pkg -> done\under{}pkg = 4
|
||||
Receiver: done\under{}pkg -> send\under{}ack = 4
|
||||
Link: received\under{}ack -> resend\under{}ack = 4
|
||||
|
||||
# Perdita per receiver
|
||||
Link: received_pkg -> resend_pkg = 4
|
||||
Receiver: recv_pkg -> is_dup = 4
|
||||
Receiver: is_dup -> send_ack = 4
|
||||
Link: received_ack -> resend_ack = 4
|
||||
Link: received\under{}pkg -> resend\under{}pkg = 4
|
||||
Receiver: recv\under{}pkg -> is\under{}dup = 4
|
||||
Receiver: is\under{}dup -> send\under{}ack = 4
|
||||
Link: received\under{}ack -> resend\under{}ack = 4
|
||||
\end{comment}
|
||||
** Proprieta`
|
||||
Sono state verificate cinque proprieta` TCTL sul modello:
|
||||
- In caso di perdita il sender o il receiver tentano nuovamente di
|
||||
inviare il pacchetto
|
||||
| link.loss --> (sender.send_pkg || sender.send_pkg1 || receiver.send_ack)
|
||||
| link.loss --> (sender.send\under{}pkg \vert{}\vert{} sender.send\under{}pkg1 \vert{}\vert{} receiver.send\under{}ack)
|
||||
questa proprieta` e` rispttata.
|
||||
- Assenza di deadlock
|
||||
| A[] (not deadlock)
|
||||
questa proprieta` e` rispettata.
|
||||
- Nonostante una perdita nel link, il sender o il receiver riceveranno
|
||||
il pacchetto
|
||||
| link.loss --> (sender.send_pkg || receiver.send_ack)
|
||||
| link.loss --> (sender.send\under{}pkg \vert{}\vert{} receiver.send\under{}ack)
|
||||
la proprieta` e` rispettata
|
||||
- Il receiver ricevera` sempre un pacchetto
|
||||
| sender.wait_ack || sender.wait_ack1 --> (sender.received_ack || sender.received_ack1)
|
||||
| sender.wait\under{}ack \vert{}\vert{} sender.wait\under{}ack1 --> (sender.received\under{}ack \vert{}\vert{} sender.received\under{}ack1)
|
||||
questa proprieta` non risulta vera dato che ci possono essere delle
|
||||
perdite nel canale
|
||||
- C'e` almeno un caso in cui l'ack ricevuto e` quello atteso
|
||||
|
|
8
anno3/vpc/consegne/Makefile
Normal file
|
@ -0,0 +1,8 @@
|
|||
all:
|
||||
cd 1 && make
|
||||
cd 2 && make
|
||||
cd 2.b && make
|
||||
cd 3 && make
|
||||
cd 4 && make
|
||||
gs -dBATCH -dNOPAUSE -q -sDEVICE=pdfwrite -dPDFSETTINGS=/prepress -sOutputFile=relazione.pdf \
|
||||
1/1.pdf 2/2.pdf 2.b/2.b.pdf 3/analisi.pdf 4/4.pdf
|
|
@ -4,7 +4,7 @@ from sys import argv
|
|||
|
||||
allsymbols = json.load(open('/home/user/UNITO/anno3/vpc/consegne/conv/unicode-latex.json'))
|
||||
|
||||
mysymbols = ['≡', '≠', '≼', '→', '←', '⊀', '⋠', '≺', '∀', 'ε', '₀', '₂', '₁', '₃', '₄', '₅', 'ₐ', 'ₖ', 'ᵥ', 'ₘ', 'ₙ', 'ᵢ', 'ⁱ', '⋮', 'ₛ', 'ₜ', '≃', '⇔', '∧', '∅', 'ℕ', 'ⱼ', 'ʲ', '⊥', 'π', 'α', 'β', '∞', 'σ', '≤', '⊈', '∧', '∨', '∃', '⇒', '∩', '∉', '⋃', 'ᵏ', 'ₗ', 'ˡ', 'ₒ', 'ᵣ', 'ᴵ', '≈', '⊆', '↦', '∪', '⊂', '℘', 'ᶜ', '⁺', 'ⁿ', 'Σ', '⁻', '∑', 'ₚ', 'τ', '↛', '→', '⋍', '∼', '≥' ]
|
||||
mysymbols = ['≡', '≠', '≼', '→', '←', '⊀', '⋠', '≺', '∀', 'ε', '₀', '₂', '₁', '₃', '₄', '₅', 'ₐ', 'ₖ', 'ᵥ', 'ₘ', 'ₙ', 'ᵢ', 'ⁱ', '⋮', 'ₛ', 'ₜ', '≃', '⇔', '∧', '∅', 'ℕ', 'ⱼ', 'ʲ', '⊥', 'π', 'α', 'β', '∞', 'σ', '≤', '⊈', '∧', '∨', '∃', '⇒', '∩', '∉', '⋃', 'ᵏ', 'ₗ', 'ˡ', 'ₒ', 'ᵣ', 'ᴵ', '≈', '⊆', '↦', '∪', '⊂', '℘', 'ᶜ', '⁺', 'ⁿ', 'Σ', '⁻', '∑', 'ₚ', 'τ', '↛', '→', '⋍', '∼', '≥', '•' ]
|
||||
extrasymbols = {'∈': '\in',
|
||||
'〚': '\llbracket',
|
||||
'〛': r'\rrbracket',
|
||||
|
|
BIN
anno3/vpc/consegne/relazione.pdf
Normal file
11
todo.org
|
@ -1,6 +1,7 @@
|
|||
* TODO VPC [16/20]
|
||||
* TODO VPC [16/21]
|
||||
- [ ] Controlla good latex
|
||||
- [ ] Uppaal muovi cartella file
|
||||
- [ ] Rimuovi "Contents" da ogni .org
|
||||
- [X] chiedi della riduzione
|
||||
- [X] calcolo semiflussi come da mail
|
||||
- [X] chiedi dell'esame
|
||||
|
@ -20,14 +21,16 @@
|
|||
- [ ] Vedi da relazioni procedure dimostrazione deadlock
|
||||
- [ ] Impara equivalenze come le spiega lei
|
||||
- [ ] Formalizza algoritmo bisimulazione
|
||||
- [-] rete A, b, c, d [4/5]
|
||||
- [X] rete A, b, c, d [5/5]
|
||||
- [X] Spiega p-t-semiflows analysis: deadlock e liveness, boundness
|
||||
- [X] sulle slide, quando si chiede come deve decidere il master
|
||||
- [X] Sistema screenshots di GSPN non tagliati
|
||||
- [X] Controlla riduzione se hai fuso posti con archi uscenti
|
||||
- [ ] Rifai la riduzione e controlla fusione con archi uscenti
|
||||
- [X] Rifai la riduzione e controlla fusione con archi uscenti
|
||||
- [ ] chiedi Daniel riduzione
|
||||
- [X] rete E, F -> Controlla sia finito
|
||||
- [X] Analisi [26/26]
|
||||
- [-] Analisi [26/27]
|
||||
- [ ] clearpage su ultime immagini
|
||||
- [X] Riduzione???
|
||||
- [X] Inverti S14 e S13
|
||||
- [X] Derivation graph errori [5/5]
|
||||
|
|