203 lines
8.1 KiB
TeX
Executable file
203 lines
8.1 KiB
TeX
Executable file
\documentclass{article}
|
|
%\usepackage{times}
|
|
\usepackage[utf8]{inputenc}
|
|
|
|
%\usepackage{amsthm}
|
|
\usepackage{algorithm} % for pseudo-codes
|
|
%\usepackage{enumerate}
|
|
\usepackage{algpseudocode}
|
|
%\usepackage{DotArrow}
|
|
%\usepackage{subfig}
|
|
%\usepackage{amsmath, environ}
|
|
%\usepackage{amssymb}
|
|
%\usepackage{amsthm}
|
|
%%\usepackage{bm}
|
|
%%\usepackage{mathtools}
|
|
\usepackage{graphicx}
|
|
%\usepackage{wrapfig}
|
|
%\usepackage{minibox}
|
|
%\usepackage{multirow}
|
|
%\usepackage{pifont} % \ding{}
|
|
%\usepackage[percent]{overpic}
|
|
%\usepackage{scrextend} % labeling environment
|
|
%
|
|
%\newtheorem{theorem}{Theorem}
|
|
%\newtheorem{definition}{Definition}
|
|
%\newtheorem{example}{Example}
|
|
%
|
|
%\renewcommand{\textfraction}{0.05}
|
|
%\renewcommand{\floatpagefraction}{0.75}
|
|
|
|
\newcommand{\centerimage}[5][-7pt]{ % [vskip] | graphics-opt | imgname | label | caption
|
|
\begin{figure}[!htb]%
|
|
\centering%
|
|
\vspace{#1}%
|
|
\includegraphics[#2]{#3}%
|
|
\caption{#5}\label{#4}\vspace{2mm}%
|
|
%\vspace{-3pt}\caption{#5}\label{#4}\vspace{-2pt}%
|
|
\end{figure}}
|
|
\date{}
|
|
%\includegraphics[trim=1cm 2cm 3cm 4cm, clip=true]{example.pdf}
|
|
|
|
|
|
|
|
\begin{document}
|
|
|
|
|
|
|
|
\title{Relazione Esercizio Rete WN (E)}
|
|
|
|
|
|
\author{Francesco Gallà, francesco.galla@edu.unito.it}
|
|
|
|
\maketitle
|
|
|
|
|
|
%=========================================================================
|
|
%%%%%%% INTRODUCTION %%%%%%%
|
|
%=========================================================================
|
|
|
|
\section{Rete E} \label{sec:reteE}
|
|
|
|
Master di tre tipi distinti (seppur di uguale struttura) che chiameremo m1, m2 e m3 e due slave (uno di struttura 1 e uno di struttura 2).
|
|
Ad ogni ciclo il master sceglie in modo indipendente di quale dei due slave servirsi.
|
|
Vi siano N master per ognuno dei tre tipi e R1 slave per la struttura 1 e R2 per la struttura 2.
|
|
|
|
%=========================================================================================================
|
|
\subsection{La rete di Petri} \label{ssec:reteE-PN}
|
|
|
|
|
|
La Figura~\ref{img:reteE} rappresenta la rete di Petri WN del primo esercizio (rete E).
|
|
Il master è modellato dai posti Req, Wait, Result e dalle transizioni Build\_req, Dispatch,
|
|
Retrieve.
|
|
Lo slave di tipo 1 è modellato dai posti Available1, S1C1,S1C2, EndS1C1, EndS2C2, EndS1 e
|
|
dalle transizioni Fork, ProcessC1, ProcessC2, Join.
|
|
Lo slave di tipo 2 è modellato dai posti Available2, S2, ResS2, EndS2, e dalle
|
|
transizioni Recv, ProcessS2, SendRes, EndS2.
|
|
|
|
Il master p\`uo scegliere in maniera indipendente a quale dei due slave mandare le richieste
|
|
grazie ai posti InBuf, InBuf1, InBuf2 e alle transizioni Choose1, Choose2, che formano un
|
|
buffer composto da 3 parti, una propria del master e una per ogni slave.
|
|
I risultati vengono ritornati al master su di un buffer condiviso tra il master e i due
|
|
slave, modellato dal posto OutBuf.
|
|
|
|
\subsection{I colori}
|
|
|
|
Questa rete utilizza una singola classe di colori chiamata Master, utilizzata per distinguere
|
|
i tipi di master ${m1, m2, m3}$. A scopo di analisi, \`e stata successivamente utilizzata la
|
|
forma ${m1..mk}$ che permette di variare le tipologie di master in maniera parametrica.
|
|
|
|
La rete utilizza il color domain $<m>$ per i posti che modellano il master e per i posti degli
|
|
slave nei quali è necessario mantenere in memoria quale master ha effettuato la richiesta.
|
|
Questo permette alle richieste di venire processate in contemporanea senza sovrapporsi.
|
|
Per i posti propri agli slave (che non si occupano quindi di processare la richiesta), non
|
|
\`e stato necessario utilizzare alcun color domain.
|
|
|
|
%\centerimage{trim=1cm 10cm 3cm 4cm, clip=true}
|
|
\centerimage{width=\columnwidth}
|
|
{reteE.jpg}{img:reteE}
|
|
{Modello WN della rete E}
|
|
|
|
|
|
\subsection{Valutazione del Reachability Graph} \label{ssec:reteE-res}
|
|
|
|
Le tabelle elencano la dimensione dello spazio degli stati al variare del numero di master e di slave (marcatura iniziale).
|
|
Per il RG, si nota come i valori di $N = 3$ e $R1,R2 = 1$ portino a tempo di calcolo di circa
|
|
??? from here until ???END lines may have been inserted/deleted
|
|
30 minuti. Inoltre ogni aumento di $R1,R2$ moltiplica linearmente il numero di 4 di un
|
|
fattore $4$ (in media) mentre tra $N = 1$ e $N = 2$ si riscontra un aumento di un fattore
|
|
$80$, mentre tra $N = 2$ e $N = 3$ si riscontra un aumento di un fattore $26$.
|
|
A causa dei tempi di calcolo eccessivi, non \`e stato possibile proseguire per ottenere un
|
|
valore più preciso riguardo l'incremento del valore di $N$.
|
|
|
|
L'utilizzo del Symbolic RG (SRG) permette di dividere di un fattore $5$ il numero di
|
|
markings rispetto al corrispettivo RG, seppure la dimensione dello spazio degli stati aumenti
|
|
in maniera coerente con il Reachability Graph. La riduzione dello spazio degli stati
|
|
ha permesso anche una riduzione del tempo di calcolo, che rimane comunque eccessivo per
|
|
procedere a successive simulazioni.
|
|
|
|
\begin{table}[h!]
|
|
\centering
|
|
\begin{tabular}{ |p{3cm}||p{3cm}|p{3cm}||p{3cm}| }
|
|
\hline
|
|
\multicolumn{4}{|c|}{Effetto della marcatura iniziale sul numero di markings} \\
|
|
\hline
|
|
N & R1,R2 & Markings RG & Markings SRG \\
|
|
\hline
|
|
1 & 1 & 2448 & 524 \\
|
|
1 & 2 & 8352 & 1750 \\
|
|
1 & 3 & 17856 & 3752 \\
|
|
2 & 1 & 179172 & 31612 \\
|
|
2 & 2 & 950787 & 165378 \\
|
|
2 & 3 & 2677328 & 463852 \\
|
|
3 & 1 & 4710272 & 799792 \\
|
|
\hline
|
|
\end{tabular} \\
|
|
\caption{Variazione dello spazio degli stati.}
|
|
\label{tab:reteE}
|
|
\end{table}
|
|
|
|
\subsection{Aumentare le tipologie di master}
|
|
|
|
Utilizzando una versione parametrica della classe di colori con $k$ come parametro, \`e stato
|
|
possibile simulare il comportamento della rete con multiple tipologie di master. $k = 3$ \`e
|
|
il punto di partenza dell'esercizio. I valori di $k$ sono stati incrementati progressivamente
|
|
cercando di mantenere il tempo di calcolo nei 30 minuti assegnati, arrivando a un valore
|
|
massimo di $k = 6$.
|
|
|
|
\`E stato utilizzato sempre lo stesso valore di $N=1,R1=1,R2=1$ per evidenziare l'impatto del
|
|
numero di master sulla rete.
|
|
|
|
Anche in questo caso, il numero di marking aumenta in maniera pressochè lineare con
|
|
l'aumentare di $k$. La differenza tra il numero di marking del Reachability Graph e quelli del
|
|
Symbolic Reachability Graph \`e per\`o notevolmente p\`iu marcata rispetto all'analisi
|
|
precedente: si nota come nel RG il numero di marking aumenti di un fattore $8$ mentre per
|
|
il SRG aumenta di un fattore $2$.
|
|
|
|
%===================== TEST 2 FMS
|
|
\begin{table}[h!]
|
|
\centering
|
|
\begin{tabular}{ |p{3cm}||p{3cm}|p{3cm}| }
|
|
\hline
|
|
\multicolumn{3}{|c|}{Effetto delle tipologie di master sul numero di marking} \\
|
|
\hline
|
|
k & Markings RG & Markings SRG \\
|
|
\hline
|
|
3 & 2448 & 524 \\
|
|
4 & 19008 & 1344 \\
|
|
5 & 143424 & 2968 \\
|
|
6 & 1057536 & 5880 \\
|
|
\hline
|
|
\hline
|
|
\end{tabular} \\
|
|
\caption{Variazione dello spazio degli stati.}
|
|
\label{tab:reteE}
|
|
\end{table}
|
|
%=====================
|
|
|
|
|
|
\subsection{Considerazioni sulla Join}
|
|
|
|
La rete E \`e una rete che utilizza classi di colore, pertanto le condizioni in cui una Join
|
|
si verifica tra due sottoprocessi che non sono stati creati dalla stessa Fork sono le seguenti:
|
|
|
|
\begin{description}
|
|
\item{1.} Sono presenti multiple istanze di token con lo stesso "colore", ovvero
|
|
identificati dallo stesso membro della classe Master (es. $<m> = m1$). Quindi \`e
|
|
necessario $N > 1$
|
|
\item{2.} Lo slave deve poter chiamare Fork su più di una richiesta per volta,
|
|
ovvero avere più di un token nel posto Available1 nella marcatura iniziale.
|
|
Questo si verifica con $R1 > 1$
|
|
\end{description}
|
|
|
|
Se queste condizioni nella marcatura iniziale sono rispettate, allora \`e possibile che si
|
|
verifichi una Join tra due processi non creati dalla stessa fork, ma che comunque
|
|
apparterranno alla stessa classe di colore (e quindi allo stesso tipo di Master).
|
|
Questo fenomeno \`e dato dal fatto che la classe Master non diversifica le richieste in
|
|
maniera univoca, ma solamente in base al master che le ha generate. Pertanto lo slave non \`e
|
|
in grado di distinguerle a sua volta.
|
|
|
|
In tutti i casi in cui le condizioni precedenti non sono rispettate, allora la Join verr\`a
|
|
per forza eseguita tra due processi figli della stessa Fork.
|
|
|
|
\end{document}
|