| blob | 68f14191bb167b8e575c8d5af23ce7b00bb21531 |
2 Nel passaggio dalla progettazione alla realizzazione del prototipo, si sono presentati diversi casi in cui si è richiesto o un adattamento del progetto o particolari accorgimenti nella codifica. Queste scelte sono dovute principalmente alle seguenti motivazioni:
4 \item \textbf{conoscenza del linguaggio}: il linguaggio scelto per lo sviluppo (Ada 2005) era, soprattutto nelle fasi iniziali, poco conosciuto. In particolare è risultato difficile il passaggio dagli altri linguaggi \textit{Object Oriented} conosciuti come \textit{Java} o \textit{C++}. Inoltre la codifica di problematiche relative alla concorrenza e soprattutto alla distribuzione hanno richiesto un ``allontanamento'' da quello che erano i soliti paradigmi di programmazione, ponendo maggiore attenzione sulla correttezza inerente a questi temi. Altre difficoltà specifiche alla sintassi del linguaggio sono state risolte invece con la pratica e l'esercizio. La possibilità di visionare altri progetti complessi scritti nello stesso linguaggio avrebbe potuto accelerare la curva di apprendimento.
5 \item \textbf{incompatibilità delle soluzioni}: le soluzioni previste in fase di progettazione si sono rivelate in fase di codifica incompatibili o comunque difficili da esprimere con la tecnologia utilizzata. Questo in alcuni casi ha portato o ad alcuni ``escamotage'' nel codice o ad una rivisitazione della soluzione.
6 \item \textbf{complessità delle componenti}: alcuni elementi, in particolare il circuito, presentavano un condensato di molte problematiche sia di concorrenza che di distribuzione. Le soluzioni più immediate non riuscivano a coprire del tutto le funzionalità richieste, portando ad una maggiore complessità. Più la soluzione prospettata risultava complessa, più era difficile verificarne la correttezza.
7 \item \textbf{sviste nella progettazione}: in alcuni casi la codifica delle componenti ha permesso di riconoscere errori o assunzioni sbagliate che rendevano inopportuna la soluzione progettata. In questi casi si è dovuta rianalizzare la problematica e agire di conseguenza.
9 Segue una presentazione delle problematiche principali, suddivise per categoria.
13 La progettazione del circuito era basata sull'assunzione che, se le macchine richiedevano in ordine l'accesso ad un settore, tale ordine sarebbe stato usato per l'assegnazione della risorsa (il settore stesso). Codificati i componenti, si sono rivelati diversi casi limite (molte macchine con le stesse performance e molto vicine) nei quali l'ordine di ingresso non risultava coerente. Il protocollo prevedeva di eseguire prima la chiamata alla procedura \textit{Exit} nel settore percorso e, al ritorno, la chiamata \textit{Enter} al tratto successivo. La soluzione migliore è risultata essere quella di rendere atomica l'invocazione di queste due procedure, evitando possibili interruzioni da parte di altri task.
14 Il risultato è stato quindi una unica procedura \textit{Release} che effettuasse senza interruzione l'uscita dal tratto e l'accodamento su quello successivo.
17 La versione iniziale del circuito prevedeva che i singoli task \textit{Car} ottenessero l'accesso in mutua esclusione alla risorsa protetta \textit{Lane} e quindi effettuassero una {delay until} simulando la percorrenza del tratto. Questa soluzione, oltre a non essere concettualmente corretta, provocava un comportamento non predicibile nell'assegnazione delle risorse. E' stato quindi deciso di modificare le modalità di percorrenza dei singoli settori, portando la chiamata \textit{delay until} all'esterno dalle risorse protette. Le procedure di \textit{delay} sono quindi diventate un semplice fattore di \textit{slow down}, ottenendo un protocollo corretto a prescindere dai tempi utilizzati. \\
18 Questo tipo di modifica ha portato ad un ulteriore cambiamento nelle modalità di ingresso ed uscita dai settori. Non essendo predicibile l'ordine di risveglio ed esecuzione dei task dopo la \textit{delay}, è risultato necessario l'algoritmo di \textit{booking} per l'uscita. Ogni task, prima di sospendersi, effettua la procedura di prenotazione dell'uscita, registrandosi con il proprio tempo di uscita calcolato. La risorsa protetta del settore si occuperà di rilasciare i task secondo questo ordine, riaccodando in una coda interna i task che cercano di uscire senza averne diritto. In questo modo l'uscita dal settore avviene in modo \textit{FIFO} e le possibilità di sorpasso dipendono solo dalle caratteristiche calcolate, e non dall'ordine di esecuzione.
21 Superati quindi questi problemi, la progettazione definitiva ha portato ad un protocollo solido e robusto, dipendente solo dai tempi calcolati e non dal tempo ``reale'' di esecuzione dei vari task.
22 Nella versione precedente del software, le uniche cose che dipendevano effettivamente dal tempo ``reale'' erano i distacchi tra le varie auto. Nella versione attuale invece, tutti i tempi sono calcolati, rendendo la simulazione completamente indipendente dall'ambiente di esecuzione.