| blob | 83cc8c2706a8589d6ed3fb0a8db98e23a0fbc752 |
4 \centering
10 %---------forse da mettere nella descrizione di track
12 In \textit{Track} sono presenti le entità protette \textit{Sector} e \textit{Lane}, che rappresentano gli elementi della pista.
13 La pista è divisa in settori, intesi come rettilinei, curve o box. Ogni settore può essere un intertempo, ovvero essere dotato degli strumenti per tenere traccia dei tempi di percorrenza.
14 La pista non è altro che un insieme ordinato (nello specifico un \textit{array}) di settori, a cui si aggiunge il settore dei box.
15 %----------------
17 \textit{Sector} è implementato come una risorsa protetta: viene ipotizzato quindi che le auto possano entrare (e uscire) una alla volta in un determinato settore.
18 Questa assunzione, anche se non rispecchia esattamente la realtà, consente una gestione più semplice e corretta della concorrenza, come si vedrà in seguito.
19 Ogni \textit{Sector} si compone di un certo numero di corsie parallele che possono essere percorse contemporaneamente da più autovetture, chiamate \textit{Lane}.
21 \textit{Lane} è implementato anch'esso come una risorsa protetta. Esso calcola, a partire dal tempo di invocazione e dalle caratteristiche dell'auto in questione, il tempo di percorrenza del tratto. Vengono eseguiti controlli sul valore calcolato, in modo da evitare i sorpassi nello stesso \textit{Lane}.
22 Gli spostamenti della chiamata da \textit{Sector} a \textit{Lane} verranno implementati come \textit{requeue}, quindi il controllo da \textit{Lane} tornerà direttamente al task che esegue \textit{PutOnPitLane}, cioè all'auto.
24 Queste scelte architetturali consentono a più auto di percorrere contemporaneamente lo stesso settore, consentendo quindi anche il sorpasso. Inoltre più auto possono percorrere contemporaneamente lo stesso \textit{Lane}, ma in questo caso non è consentito alle auto di superarsi.
26 Nella figura \ref{fig:attivita} è rappresentato il protocollo di percorrenza del circuito. Come si vede, la chiamata a \textit{Release\_and\_Enter}, che fa uscire un auto da un settore e la fa automaticamente entrare nel settore successivo, ritorna un valore \textit{Time}, che indica il tempo al quale l'auto avrà terminato di percorrere quel tratto. L'auto eseguirà quindi una chiamata \texttt{delay until Time;}, ma prima dovrà comunicare questo tempo di uscita al settore interessato attraverso la procedura \textit{BookExit} con parametro \textit{Time}. Scaduto questo tempo, l'auto è pronta per percorrere il settore successivo, seguendo la stessa procedura.
28 La scelta di rendere atomiche l'uscita da un settore e l'entrata nel successivo è dovuta al fatto che, tenendo \textit{Relase} ed \textit{Enter} separate e ritornando quindi il controllo al chiamante \textit{PutOnPitLane}, non sarebbe stato possibile prevedere l'ordine di esecuzione, cioè l'ordine di ingresso nel settore successivo. Inoltre le differenze nei tempi di risveglio potrebbero essere inferiori alla granularità dell'orologio che gestisce la \textit{delay until}, portando ad avere sorpassi indesiderati.
30 La scelta di tenere la procedura \textit{BookExit} esterna, invece che invocarla automaticamente dalla \textit{Release and Enter} è stata fatta per la maggior semplicità nel protocollo di ritiro delle auto.
32 La procedura \textit{Release} utilizza il modello a guscio d'uovo del componente \textit{Sector}. Se infatti un'auto invoca \textit{Release} quando ancora non è il suo turno di uscita (l'ordine d'uscita è conosciuto e mantenuto sempre coerente in una struttura dati interna a \textit{Sector}), la chiamata viene riaccodata in una coda interna, governata da una guardia di Dijkstra, fino a quando \textit{Release} verrà invocata da un'altra auto. Se è quest'ultima l'auto che deve uscire, viene aperta la guardia della coda interna e le auto in attesa vengono fatte uscire, sempre rispettando l'ordine. Altrimenti anche questa seconda auto viene accodata nella coda interna, in attesa che l'auto che le precede esegua la stessa procedura.
36 Il componente Race è implementato come un tipo task. Si tratta di un \textit{server}, cioè un tipo di entità reattiva. L'esecuzione delle varie chiamate avviene quindi in mutua esclusione. Questo permette di assegnare senza incorrere in \textit{race condition} gli \textit{ID} alle auto registrate. Inoltre l'esecuzione in mutua esclusione delle chiamate semplifica la gestione delle classifiche e dei monitor.
38 \textit{Race} infatti ha anche il ruolo di gestione delle statistiche. Logicamente è la gara che conosce la classifica ed i vari tempi di percorrenza sull'intermedio e sul giro dei singoli concorrenti. \textit{Race} si occupa quindi di ricevere informazioni sulle percorrenze da \textit{Track}, elaborare tali dati ottenendo informazioni derivate (ad esempio il tempo sul giro) e diffondere queste informazioni ai monitor tramite un protocollo di comunicazione che segue il modello della \textit{push notification}.
39 Tutte le chiamate relative alle statistiche sono implementate come asincrone.
43 Monitor, per sua natura, è strettamente correlato alla propria GUI. Coerentemente con i messaggi ricevuti da gara, viene creata una struttura dati GTK che, ne permette la visualizzazione. La concorrenza in questo componente si limita alla mutua esclusione nell'accesso alla struttura dati, che viene garantita da apposite chiamate GTK con cui racchiudere la sezione critica.
47 Il protocollo di partenza emula quello che accade nel mondo reale. Si fissa un ordine di partenza, che può dipendere dall'\textit{id} delle auto o essere randomizzato.
48 Quando arriva il segnale di inizio gara, la prima auto inizia a percorrere il primo settore. In particolare, effettua una chiamata a \textit{Enter}. Solo a questo punto, l'auto notifica alla successiva
49 che può partire. Questo protocollo di partenza ``simula'' l'idea di una fila indiana, in cui ogni auto può partire solo dopo che l'auto precedente è partita.
50 Questa soluzione sembra un giusto compromesso tra semplicità e quello che accade nel mondo reale.
56 La simulazione avviene interamente nel componente \textit{Track}. I tempi necessari alla simulazione (tempo di avvio della gara) sono riferiti solo all'orologio locale del nodo in cui esegue questa componente. Non si presentano quindi problemi legati alla sincronizzazione degli orologi.
57 Inoltre i tempi di percorrenza sono tutti relativi (\textit{Duration}), quindi completamente indipendenti dall'orologio di sistema.
59 L'ordine di ingresso in un settore è controllato da una risorsa protetta (il settore precedente) che ne assicura la correttezza a prescindere dall'ordine di esecuzione.
61 I tempi di percorrenza si basano solo sui tempi calcolati, quindi il protocollo è corretto indipendentemente dall'ordine e dal tempo di esecuzione.
63 Il tempo di percorrenza di un settore dipende esclusivamente dalle caratteristiche dell'auto, ed è quindi indipendente dall'esecuzione concorrente.
65 L'unico caso in cui il tempo calcolato viene modificato è quando la corsia di percorrenza è affollata. In questo caso il tempo di percorrenza dell'auto viene aumentato in modo che il tempo d'uscita dal settore non sia inferiore di quelli delle auto che precedono.
66 L'accodamento nelle varie corsie avviene tramite un algoritmo: viene scelta la corsia meno affollata. E' quindi decidibile e non dipende dall'ambiente di esecuzione.
68 I problemi maggiori dipendono dal fatto che i task possono alternarsi nell'esecuzione in maniera (per noi) non predicibile. Si sono presentati diversi problemi riguardo questa tematica. Di seguito ne elenchiamo alcuni, con le relative soluzioni.
70 \item i risvegli delle auto dalla delay possono non avvenire in ordine : la soluzione è stata l'introduzione di un protocollo di \textit{booking}, cioè le auto comunicano ai settori quale sarà il loro tempo di uscita. La procedura che implementa questa idea
71 è chiamata \textit{BookExit}. In pratica, si tratta di una soluzione algoritmica ad un ordine di esecuzione dei processi non corretto.
73 Le auto riescono ad uscire dal settore solo rispettando l'ordine di uscita calcolato sui tempi comunicati in precedenza.
74 Un task che esegue in un momento non previsto, non ha la possibilità di uscire, viene riaccodato nella coda interna, e deve attendere
75 l'esecuzione degli altri task. Questi task eseguiranno sicuramente, poichè se un'auto intende ritirarsi, non effettuerà la chiamata a \textit{BookExit},
76 quindi non risulterà presente nella lista dei tempi di uscita. Questo protocollo non compromette i tempi di percorrenza.
78 \item Tra l'uscita da un settore e l'entrata nel successivo, l'ordine di esecuzione dei task potrebbe cambiare (prerilascio).
79 La soluzione è stata rendere atomiche l'uscita da un settore e l'entrata nel successivo. L'implementazione è una \textit{requeue} dal metodo \textit{Release} di un settore,
82 \item Coerenza dei tempi: il tempo di calcolo che intercorre tra il risveglio dalla \textit{delay until} al calcolo del tempo di risveglio nel settore successivo, non viene tenuto in considerazione.
83 Il tempo di calcolo è quindi irrilevante. Questo tempo di calcolo, anche se fosse molto grande e diverso per ogni auto,
84 non potrebbe in alcun modo influire sull'ordine di percorrenza, sui distacchi o sui tempi sul giro.
85 I tempi sul giro ed i distacchi sono infatti calcolati come somma dei tempi dei singoli settori.
88 La gestione dei tempi di gara sembra risultare corretta e coerente. Auto con le stesse caratteristiche hanno identici tempi di percorrenza ( a parte nel primo giro per i tempi di partenza diversi).