COLLOQUIO PROCESSI - DRIVER

M

Processo  O

interno N

I attivazione periferica

T processo processo esterno

O driver (periferica)

R interruzione

Il MONITOR rappresenta dunque la periferica. La struttura dati del monitor riproduce la rappresentazione interna della periferica: registri di interfaccia, area buffer di dati, variabili condition utilizzate per la sincronizzazione di processi, etc.. Le procedure del driver identificano le operazioni che possono essere eseguite su quella periferica.

Facciamo un esempio pratico, tratto dall'Ancilotti-Boari, relativo alla gestione di un terminale video e scritto secondo la sintassi del linguaggio concorrente MODULA 2. In tale linguaggio DEVICE MODULE è sinonimo di monitor, SIGNAL di condition e SEND di signal (su variabile condition), mentre l'istruzione DEFINE serve per definire procedure ENTRY (accessibili quindi all'esterno del modulo).

DEVICE MODULE video ;

define put ;

var in, out, num: integer ;

non_pieno, non_vuoto: signal ;

coda: array 0.. n-1 of char ;

procedure put (x: char) ; /* questa procedura è eseguita esclusivamente

dal processo utente */

begin

if num = n then WAIT (non_pieno) ;

coda in  : = x ;

in : = (in + 1) mod n ;

num : = num + 1 ;

SEND (non_vuoto) ; /* corrisponde ad una SIGNAL inviata al driver */

end ;

Il processo utente pone i caratteri da stampare a video in una coda e il driver li stampa; riportiamo di seguito il testo del processo driver (il MODULA 2 consente di inserire un processo all'interno di un monitor).

Process driver  64B /* le espressioni tra parentesi quadre sono

indirizzi di mappatura hardware */

var stato 177564B : bits ; /* status register dell'interfaccia */

buf 177566B : char ; /* buffer register dell'interfaccia */

begin

loop

if num = 0 then WAIT (non_vuoto) ;

buf = coda out

out : = (out + 1) mod n ;

stato  : = true ; /* questo è un segnale di strobe per impostare la periferica

in stato ready; questa istruzione abilita le interruzioni

della periferica e la successiva DOIO ha l'effetto di

porre il processo driver in attesa

dell'interruzione di fine trasferimento */

DOIO

stato  : = false ; /* abbassamento dello strobe */

num : = num - 1 ;

SEND (non_pieno) ; /* SIGNAL inviata al processo utente */

end ;

end ;

begin /* inizializzazione */

in : = 0 ;

out : = 0 ;

num : = 0 ;

driver /* creazione del processo driver */

end. 

Il processo utente deve soltanto invocare la procedure entry put per l'invio di un carattere a video. La struttura dati è sostanzialmente una coda di n caratteri necessaria per conservare memoria dei caratteri già inviati dall'utente ma non ancora consumati dal driver. Dal canto suo, driver è un processo ciclico che, mentre la coda non è vuota, continua a prelevare un carattere alla volta e ad inviarlo, mediante l'operazione DOIO, alla periferica.

Come indicato anche nel commento all'interno del codice, DOIO sta in effetti per wait_for_interrupt; all'esecuzione di questa istruzione, dunque, il driver si pone in attesa di un segnale di interruzione dalla periferica. Quando arriva l'interruzione la ISR si occupa di far ripartire il driver dall'istruzione successiva alla DOIO.

Per semplicità si è scelto di inserire il driver direttamente all'interno del monitor, invece di realizzare un più generale modello produttore (utente) consumatore (driver). Questa sarebbe stata comunque una soluzione più conveniente. In questo caso avremmo considerato due buffer anziché uno solo, distinguendo cioè il buffer di memoria nel quale il produttore deposita i caratteri dal buffer dal quale gli stessi vengono prelevati dal driver. Avremmo poi avuto due procedure: PRODUCI e CONSUMA, la seconda delle quali incaricata di prendere i dati dal buffer del produttore e di spostarli in un buffer interno al driver. Il driver sarebbe stato esterno al monitor. Questo modo di procedere presenta il vantaggio di aumentare il grado di parallelismo: l'operazione di I/O (driver) può essere realizzata parallelamente alle operazioni di bufferizzazione.