Appunti sullo sviluppo di Phase 2

[Scheduler]

Si e' scelto di rendere il piu' modulare possibile lo scheduler, distinguendo la specifica azione di scheduling, intesa come il calcolo del nuovo processo da mandare in esecuzione e del relativo tempo da assegnargli, dalla piu' generica azione di dispatching, intendendo il complesso delle attivita' che sono invece proprie della struttura di Phase 2. Si sono quindi definiti i confini della capsula che lo avvolge, oscurando i dettagli implementativi al suo interno e al contempo palesare l'interfaccia verso l'esterno, al fine di poter favorirne l'adattabilita'.

Non sarebbe una cattiva idea confinare lo scheduler in un modulo tutto suo, magari spostando l'incarto che al momento lo avvolge all'interno del codice di gestione dell'interrupt 2.

[TODO]: descrizione accurata delle interfacce

[CPU Timing]

L'accounting dei tempi di CPU utilizzati dai vari processi viene realizzato tenendone traccia in un campo del processo. L'uso della CPU e' da distinguersi in due tipi: uso diretto e indiretto. Ci si riferisce al primo nel caso il processo stia utilizzando effettivamente il processore con il suo codice, mentre si parla di uso indiretto quando il codice e' in realta' esterno al processo stesso [syscall e interrupts handling (e anche lo stesso tempo richiesto allo scheduling ?)].

Chi si preoccupa di tenere traccia dell'uso diretto e' lo stesso dispatcher, che fara' un timestamp prima del caricamento del pcb, e, una volta reinvocato per la successiva ri-schedulazione, calcolera' la differenza.

Nel caso di uso indiretto, il compito e' ripartito fra i gestori delle eccezioni: essi addebiteranno il proprio tempo di esecuzione al processo chiamante (procCurr) nel caso di syscall, trap e breakpoint, oppure al processo realmente interessato nel caso di interrupt; in questo ultimo scenario l'identificazione dell'interessato avviene al momento di verhogen-are un semaforo.

Varie ed eventuali

Prima di fare passeren si dovra' chiamare dsp_markSleep(procCurr) e poi dispatcher().