Hello, if you have any need, please feel free to consult us, this is my wechat: wx91due
Progetto SO 2023/24
Reazione a catena
Versione provvisoria dell’11 dicembre 2023
Bini, Radicioni, Schifanella C.
November 2023
1 Composizione gruppo di studenti
Il progetto sar`a sviluppato da un gruppo, composto da 1 a massimo 3 componenti. Il gruppo dovrebbe essere composto da studenti dello stesso turno, i quali discuteranno con il docente del proprio turno. E tuttavia consentita ` anche la discussione del progetto di laboratorio da parte di un gruppo di studenti di turni diversi. In questo caso, tutti gli studenti del gruppo discuteranno con lo stesso docente. Esempio: Tizio (turno T1) e Caio (turno T2) decidono di fare il progetto insieme. Lo consegnano e vengono convocati dal prof. Sempronio il giorno X. Tale giorno Tizio e Caio si presentano e ricevono entrambi una valutazione dal Prof. Sempronio (docente del T1, anche se Caio fa parte del turno T2, il cui docente di riferimento `e il prof. Calpurnio).
2 Consegna
Il progetto `e costituito da:
11. il codice sorgente
2. una breve relazione che sintetizzi le scelte progettuali compiute
Il progetto si consegna compilando la seguente Google Form, cui si accede con credenziali istituzionali,
❼ https://forms.gle/SH9Ny25JsweSjy359
la quale richieder`a il caricamento di:
❼ progetto stesso (un unico file in formato .tgz o .zip NON .rar). Il nome del file deve essere composto dall’unione
dei cognomi dei componenti del gruppo (es.: TizioCaio.zip)
❼ cognome, nome, matricola, email di ciascun componente del gruppo.
Dopo il caricamento del progetto, verrete convocati dal docente con cui discuterete (si veda Sezione 1 in caso di gruppo composto da studenti di turni diversi). Attenzione: compilare una sola form per progetto (e non una per ogni componente del gruppo). Una eventuale ulteriore consegna prima dell’appuntamento annuller`a la data dell’appuntamento.
La consegna deve avvenire almeno 10 giorni prima degli appelli scritti per dare modo al docente di pianificare i colloqui:
❼ se consegnate con almeno 10 giorni di anticipo rispetto alla data di un appello, il docente propone una data per la discussione entro l’appello seguente
❼ altrimenti, la data sar`a successiva all’appello seguente.
Esempio: per avere la certezza di un appuntamento per la discussione di progetto entro l’appello del 19/01/2023, si deve consegnare entro le ore 24:00 di Marted`ı 09/01/2023.
3 Valutazione e validit`a
Il progetto descritto nel presente documento potr`a essere discusso se consegnato entro il 30 Novembre 2024.
Dal Dicembre 2024 sar`a discusso il progetto assegnato durante l’anno accademico 2024/25.
Tutti i membri del gruppo devono partecipare alla discussione. La valutazione del progetto `e individuale ed espressa in 30-esimi. Durante la discussione
❼ verr`a chiesto di illustrare il progetto
❼ verr`a chiesto di commentare il codice e eventualmente di apportare piccole modifiche al progetto
❼ verranno proposti quesiti sul programma “Unix” del corso anche non necessariamente legati allo sviluppo del progetto.
E necessario ottenere una votazione di almeno ` 18 su 30 per poter essere ammessi allo scritto. In caso di superamento della discussione del progetto, la votazione conseguita consentir`a di partecipare allo scritto per i cinque appelli successivi alla data di superamento. Non sono ammesse eccezioni o deroghe a tale periodo di validit`a.
In caso di mancato superamento, lo studente si potr`a ripresentare soltanto dopo almeno un mese dalla data del mancato superamento
Si ricorda che il voto del progetto ha un peso di 1
4
sulla votazione finale di Sistemi Operativi.
4 Pubblicazione del proprio progetto, plagio, sanzioni
Copiare altri progetti o parte di essi impedisce una corretta valutazione. Per questo motivo, gli studenti che consegnano il progetto sono consapevoli che:
❼ la condivisione con altri gruppi attraverso canali pubblici o privati (a titolo di esempio: google drive, canali telegram, github, etc.) di tutto o parte del progetto non `e consentita fino a tutto Novembre 2024;
❼ la copiatura di tutto o parte del progetto non `e consentita;
❼ eventuali frammenti di codice estratti da parti di codice visto a lezione o da altri repository pubblici devono
essere opportunamente dichiarati.
Nel momento in cui uno studente non rispettasse le sopra citate norme di comportamento, dopo essere stato convocato ed aver avuto modo di illustrare la propria posizione, potr`a essere oggetto delle seguenti sanzioni:
❼ se lo studente avr`a nel frattempo superato l’esame di Sistemi Operativi anche successivamente alla data di discussione del progetto, la verbalizzazione del voto verr`a annullata;
❼ se lo studente avr`a soltanto superato la discussione del progetto ma non l’esame, la valutazione del progetto verr`a annullata e lo studente non potr`a accedere ad ulteriore discussione di progetto prima dei due appelli successivi alla data di evidenza di copiatura.
5 Descrizione del progetto: versione minima (voto max 24 su 30)
Si intende simulare una reazione a catena. A tal fine sono presenti i seguenti processi:
❼ un processo master che gestisce la simulazione e mantiene delle statistiche
❼ processi atomo che si scindono in altri processi atomo, generando energia
❼ un processo attivatore
❼ un processo alimentazione che aggiunge nuovi atomi
5.1 Processo master
Il processo master
❼ gestisce la simulazione, inizializza le strutture, crea processi figlio
❼ ogni secondo:
– stampa lo stato corrente della simulazione e le statistiche
– preleva una quantit`a ENERGY DEMAND di energia.
All’inizio della simulazione, il processo master
❼ crea N ATOMI INIT processi atomo
❼ crea il processo attivatore
❼ crea il processo alimentazione
❼ avvia la simulazione. La simulazione dovr`a partire solamente quando tutti i processi sopra citati sono stati creati e hanno eseguito le rispettive istruzioni di inizializzazione
5.2 Processo atomo
Ogni processo atomo `e dotato di un numero atomico casuale compreso tra 1 e N ATOM MAX. Il numero atomico `e un’informazione privata del processo che viene assegnata dal processo padre dopo la sua creazione (la funzione di scelta del numero atomico `e demandata al programmatore. Pu`o essere estratto un semplice numero casuale o utilizzata qualche altra distribuzione di probabilit`a).
La scissione dell’atomo `e simulata con una fork.
❼ Un processo atomo padre effettua una fork di un nuovo atomo.
❼ La somma dei numeri atomici di padre e figlio dopo la scissione `e uguale a quello del padre prima della scissione.
❼ Quando avviene la scissione, viene incrementata l’energia liberata nelle statistiche mantenute dal master. La quantit`a di energia liberata dipende dai numeri atomici dei due atomi dopo la scissione, secondo la seguente funzione energy(n1, n2) = n1n2 − max(n1, n2), con n1 e n2 uguali ai numeri atomici dei due atomi dopo la fissione. Si osservi che l’energia liberata `e massima quando avviene una scissione in atomi con ugual numero atomico, mentre vale 0 quando n1 o n2 vale 1.
❼ La scissione `e comunicata dal processo attivatore. Tale meccanismo di comunicazione `e scelto a discrezione dello sviluppatore (si possono pensare a soluzioni alternative con pipe, code di messaggi, semafori, o segnali).
❼ Quando un atomo con numero atomico minore o uguale a MIN N ATOMICO riceve il comando di scissione, esso termina e viene conteggiato nelle statistiche fra le scorie.
5.3 Processo attivatore
Sulla base di proprie politiche (a discrezione degli sviluppatori), il processo attivatore comunica a uno o pi`u atomi la necessit`a di effettuare una scissione.
Nota bene: l’attivatore NON crea nuovi atomi, ma ordina esclusivamente ad atomi presenti di scindersi.
Saranno gli atomi che a loro volta ne creeranno di nuovi.
5.4 Processo alimentazione
Ogni STEP nanosecondi, il processo alimentazione immette nuovo combustibile, ovvero crea N NUOVI ATOMI atomi.
5.5 Terminazione
La simulazione termina in una delle seguenti circorstanze:
timeout raggiungimento della durata impostata SIM DURATION explode energia liberata (al netto di quella consumata da master) maggiore del valore ENERGY EXPLODE THRESHOLD blackout prelievo di una quantit`a di energia maggiore di quella disponibile. La quantit`a di energia disponibile `e definita come la quantit`a di energia prodotta dalla scissione degli atomi meno la quantit`a di energia prelevata dal processo master. meltdown fallimento delle fork di uno qualunque dei processi
Il gruppo di studenti deve produrre configurazioni che siano in grado di generare la terminazione in ognuno dei casi sopra descritti.
Al termine della simulazione, l’output del programma deve riportare anche la causa di terminazione.
6 Descrizione del progetto: versione “normal” (max 30)
Nella versione completa del progetto, `e presente anche un processo inibitore che controlla reazione attraverso i seguenti due meccanismi:
❼ assorbe parte della quantit`a di energia prodotta dalla scissione dell’atomo diminuendo la quantit`a di energia che viene liberata
❼ limita il numero di scissioni agendo sull’operazione di scissione rendendola probabilistica (ad esempio decidendo se la scissione debba avvenire o meno oppure trasformando in scoria uno degli atomi prodotti dopo la scissione)
Il meccanismo di assorbimento e quello di limitazione delle scissioni sono scelti dal programmatore e devono essere basati su qualche criterio probabilistico.
La presenza o meno del processo inibitore deve poter essere scelta a run-time, all’inizio della simulazione. Nel caso in cui il processo inibitore sia attivo, ci si aspetta che la terminazione per “explode” e “meltdown” non avvenga.
Inoltre, l’utente deve poter fermare (e far ripartire) il processo inibitore pi`u volte da terminale attraverso un meccanismo a scelta del programmatore.
7 Configurazione
Tutti i parametri di configurazione sono letti a tempo di esecuzione, da file o da variabili di ambiente. Quindi, un cambiamento dei parametri non deve determinare una nuova compilazione dei sorgenti (non `e consentito inserire i parametri uno alla volta da terminale una volta avviata la simulazione).
8 Linee guida per la valutazione
Ogni secondo il sistema deve produrre una stampa in cui sono elencati:
❼ numero di attivazioni occorse ad opera del processo attivatore (totali e relative all’ultimo secondo),
❼ numero di scissioni (totali e relative all’ultimo secondo);
❼ quantit`a di energia prodotta (totale e relativa all’ultimo secondo);
❼ quantit`a di energia consumata (totale e relativa all’ultimo secondo);
❼ quantit`a di scorie prodotte (totale e relativa all’ultimo secondo);
❼ (per la versione “normal”) quantit`a di energia assorbita dal processo inibitore
❼ (per la versione “normal”) log delle operazioni di bilanciamento condotte dal processo inibitore.
9 Requisiti implementativi
Il progetto (sia in versione “minimal” che “normal”) deve
❼ evitare l’attesa attiva
❼ utilizzare almeno memoria condivisa, semafori e un meccanismo di comunicazione fra processi a scelta fra code di messaggi o pipe,
❼ essere realizzato sfruttando le tecniche di divisione in moduli del codice (per esempio, i vari processi devono essere lanciati da eseguibili diversi con execve(...)),
❼ essere compilato mediante l’utilizzo dell’utility make
❼ massimizzare il grado di concorrenza fra processi
❼ deallocare le risorse IPC che sono state allocate dai processi al termine del gioco
❼ essere compilato con almeno le seguenti opzioni di compilazione: gcc -Wvla -Wextra -Werror
❼ poter eseguire correttamente su una macchina (virtuale o fisica) che presenta parallelismo (due o pi`u processori).
Per i motivi introdotti a lezione, ricordarsi di definire la macro GNU SOURCE o compilare il progetto con il flag -D GNU SOURCE.