Processi e processori

Transcript

1 Architettura degli Elaboratori, a.a Processi e processori Queste note hanno i seguenti scopi: operare da collante tra varie parti del corso (macchina assembler, architettura del processore, gerarchie di memoria, introduzione ai sistemi operativi), fornendo una traccia secondo la quale utilizzare il materiale didattico; integrare (sez. 1, 2, 3, parte introduttiva della sez. 4) la parte I del corso sulla strutturazione complessiva dei sistemi a livelli ed a moduli; integrare (sez. 4) la parte II del corso sulla macchina assembler; integrare (sez. 5, 6) la parte V del corso sull introduzione ai sistemi operativi. 1. Compilazione e interpretazione Modello di calcolatore general-purpose a programma memorizzato I livelli assembler e firmware di un calcolatore general-purpose Memoria virtuale e spazio di indirizzamento Inizializzazione di variabili Trasferimenti di ingresso-uscita Caricamento ed esecuzione di un programma Processi cooperanti Dai programmi ai processi Processi cooperanti a scambio di messaggi Sistema operativo e compilazione di programmi applicativi Introduzione ai sistemi operativi: il nucleo Scheduling a basso livello, architettura astratta e architetture concrete Interruzioni ed eccezioni Prerilascio e quanti di tempo Indivisibilità Spazi di indirizzamento Indirizzamento di strutture dati di nucleo Esempio di implementazione di primitive di comunicazione...14

2 2 1. Compilazione e interpretazione Il fine ultimo di un calcolatore è quello di rendere possibile l esecuzione di programmi. Cominciamo con il caratterizzare questa generica affermazione: 1. i programmi vengono progettati mediante linguaggi ad alto livello. Per ragioni di efficienza e di generalità, occorre prevedere una traduzione da linguaggio ad alto livello in una forma intermedia, detta linguaggio macchina o linguaggio assembler. Le caratteristiche di questo linguaggio emergeranno dall analisi successiva; 2. i calcolatori a cui ci riferiamo devono permettere l esecuzione di qualunque programma: devono cioè essere general-purpose. Come sempre accade, coniugare generalità ed efficienza è un problema complesso: uno dei principali obiettivi dell Architettura degli Elaboratori è dare soluzioni ragionevoli a questo problema; 3. la traduzione dal programma sorgente (in gergo, codice sorgente ) scritto in linguaggio ad alto livello, nel programma oggetto o eseguibile (in gergo, codice oggetto o codice eseguibile ), espresso in linguaggio assembler, può essere effettuata secondo una delle due ben note tecniche, la compilazione e l interpretazione, o loro combinazioni. In entrambi i casi, il punto di partenza è una sequenza di comandi, costituenti il programma scritto nel linguaggio ad alto livello, operanti su determinati insiemi di dati. Un compilatore o un interprete sono essi stessi dei programmi, già disponibili in forma eseguibile, che accettano come dato d ingresso il programma sorgente (una rappresentazione opportuna della sequenza di comandi e rispettivi dati) e producono come dato di uscita il programma eseguibile; 4. un traduttore di tipo interprete scandisce tale sequenza sostituendo ogni singolo comando con una sequenza di istruzioni assembler nota, detta l interprete di quel comando. Questa forma di traduzione è effettuata dinamicamente, cioè a tempo di esecuzione, da cui la dizione, equivalente a quella di interprete di un linguaggio, di supporto a tempo di esecuzione di quel linguaggio; 5. un traduttore di tipo compilatore sostituisce l intera sequenza del programma sorgente con una sequenza di istruzioni assembler. Questa forma di traduzione è effettuata staticamente, cioè in fasi di preparazione prima che il programma passi in esecuzione. Anche il compilatore deve disporre di regole per sostituire ogni comando del programma sorgente con il rispettivo supporto a tempo di esecuzione, ma, a differenza dell interpretazione: la compilazione prende in esame tutto il programma sorgente, per ogni comando del linguaggio sorgente, esistono più sequenze eseguibili per tenere conto efficientemente del contesto in cui il comando si trova ad essere inserito. Per esemplificare la differenza tra compilazione e interpretazione, si considerino i due seguenti frammenti di programmi: /programma 1/ int A[N], B[N]; for (i = 0; i < N; i++) A[i] = A[i] + B[i]; /programma 2/ int a; int B[N]; for (i = 0; i < N; i++) a = a + B[i]; In entrambi i casi si tratta di tradurre un comando di tipo for, contenente un comando di assegnamento su dati con tipi opportuni. Mentre nel primo caso ad ogni passo del for viene calcolato un nuovo valore di un nuovo elemento del vettore A, nel secondo caso ad ogni passo del for viene calcolato un nuovo valore della stessa variabile scalare a. Un compilatore utilizzerà modalità diverse per produrre il codice oggetto del comando di assegnamento: nel programma 1 ad ogni passo del for provocherà la modifica della rappresentazione eseguibile del vettore A; nel programma 2, utilizzerà una rappresentazione temporanea dello scalare a, al quale verranno assegnati tutti i successivi valori, finché, all uscita del for, la variabile temporanea verrà scritta nella rappresentazione finale della variabile a, disponibile per successivi usi da parte del seguito del programma. La rappresentazione temporanea di a è più efficiente della rappresentazione finale (tipicamente, il temporaneo risiede in un registro, la rappresentazione finale in una locazione di memoria principale; l accesso in memoria comporta ritardi decisamente maggiori rispetto all accesso ad un registro). Un interprete traduce il comando di assegnamento del programma 1 e del programma 2 nello stesso modo: nel secondo caso non viene utilizzato un temporaneo, ma esiste un unica rappresentazione della variabile a il cui valore viene ripetutamente modificato (viene letto N volte e scritto N volte il valore di a direttamente in memoria, effettuando 2*(N- 1) accessi in memoria in più rispetto alla versione compilata).

3 3 In generale nella traduzione da parte di un interprete, poiché questa avviene passo passo, non viene considerato il contesto in cui si trova il comando da interpretare a ogni passo, applicando sempre la stessa regola di traduzione per uno stesso comando; invece, la traduzione da parte di un compilatore prende in considerazione una sequenza, più o meno ampia, in cui si trova inserito un comando e, per uno stesso comando, applica regole di traduzione diverse allo scopo di ottimizzare le prestazioni (ad esempio, il tempo di elaborazione del programma e/o l occupazione di memoria). La fase di ottimizzazione è in effetti quella che caratterizza più pesantemente un compilatore: allo stato attuale della tecnologia, nel confronto tra due calcolatori di costruttori diversi, quello con il compilatore migliore può talvolta riuscire a colmare il gap prestazionale dovuto ad un processore peggiore. Sempre per rimanere all esempio precedente, si può vedere un ulteriore occasione di ottimizzazione passando dalla versione interpretata alla versione compilata: a seconda del valore di N, l esecuzione del for può consistere in una o più iterazioni (esecuzione tipo do while), oppure non aver luogo nessuna iterazione. Un interprete effettuerà sempre, all inizio di un for, un controllo su N per distinguere le due situazioni, e, per N 0, la gestione del loop verrà effettuata sempre allo stesso modo per qualunque valore di N. Invece, un compilatore sfrutterà la conoscenza sul valore di N disponibile staticamente: se N > 0 verrà generato codice assembler per la gestione di un loop ripetuto più di una volta (nell esempio, essendo N la dimensione di un array, questo è l unico caso), se N = 0 verrà generato codice per il solo corpo del for senza generare codice per la gestione del loop, se N < 0, non verrà generato codice, passando direttamente alla parte successiva del programma. Una classe importante di ottimizzazioni a tempo di compilazione è quella relativa la miglior sfruttamento delle caratteristiche architetturali, ad esempio la memoria cache e/o l architettura internamente parallela di processori. Sulle caratteristiche di compilatori e interpreti torneremo frequentemente durante il corso. Vale fin da ora la pena di rimarcare che: a) anche nel caso della pura interpretazione, è sempre presente un minimo di compilazione, consistente nelle rappresentazione del programma sorgente in un formato facilmente comprensibile all interprete; b) raramente siamo in presenza di linguaggi soggetti a compilazione pura o a interpretazione pura. Ad esempio, anche in linguaggi che facciano soprattutto uso di compilazione, il supporto di eventuali comandi per esprimere strutture dati dinamiche in modo primitivo (come new o malloc) è necessariamente implementato mediante interpretazione; c) interessante è il caso, utilizzato in popolari linguaggi ad oggetti, di on the fly compilation : la prima esecuzione di un programma (o una sua fase iniziale di esecuzione) è soggetta a interpretazione, dopo di che, in base alla conoscenza acquisita sul suo comportamento, il programma può venire parzialmente ristrutturato per introdurre ottimizzazioni tipiche di un compilatore. 2. Modello di calcolatore general-purpose a programma memorizzato Nell architettura firmware di un calcolatore general-purpose, un ruolo chiave è svolto dal Processore: il microprogramma di questa unità di elaborazione (che, come per qualunque unità, definisce il suo funzionamento è la sua struttura) è l interprete del linguaggio assembler, permettendo quindi l esecuzione del programma in versione eseguibile. Ci si potrebbe chiedere perché il livello firmware è un interprete e non un compilatore : in effetti, si può dimostrare che, nella strutturazione a livelli di un sistema di elaborazione, almeno il livello più basso deve essere un interprete. Nel caso della strutturazione tipica (vedi Cap. I della Dispensa), esistono almeno due interpreti: quello a livello firmware (che interpreta l assembler) e quello a livello hardware (che interpreta il firmware). Al più, si potrebbe pensare di compilare l assembler in firmware, con che il vero linguaggio macchina diverrebbe il microlinguaggio, rendendo di fatto inutile il livello assembler; questa soluzione, che è stata adottata con successo nel passato, non è più conveniente alla luce dell evoluzione della tecnologia VLSI (occorrerebbe realizzare processori microprogrammabili ). D altra parte, specie se le istruzioni assembler sono semplici (approccio Risc), i microprogrammi risultano notevolmente ottimizzati anche in un approccio interpretato. Con la terminologia del Cap. III della Dispensa, le istruzioni assembler sono le operazioni esterne dell unità di elaborazione Processore. Una volta stabilito di realizzare di realizzare il Processore come interprete del linguaggio assembler, discende che, nell architettura firmware del calcolatore, occorre prevedere anche una unità Memoria Dati, nella quale fare risiedere le strutture dati riferite dal programma eseguibile, ed un insieme di Unità di Ingresso/Uscita per trasferire dati a/da tale memoria (dischi, monitor, tastiere, mouse, stampanti, interfacce di rete, ecc). Inoltre, occorre prendere una decisione cruciale relativamente all architettura complessiva del calcolatore:

4 4 quale modello di programmazione segue il linguaggio assembler? come vengono fatte pervenire al Processore le richieste di esecuzione delle istruzioni assembler (operazioni esterne), in modo da rispettarne efficientemente l ordinamento a tempo di esecuzione? La risposta al primo quesito comporta una risposta al secondo. Ad esempio, avremmo architetture completamente diverse a seconda che il modello di programmazione del linguaggio assembler fosse puramente funzionale oppure imperativo. La scelta universalmente adottata ormai da molti anni è la seguente: il modello di programmazione a livello assembler è imperativo (per comprenderne a fondo i motivi, occorre studiare aspetti avanzati di Architettura degli Elaboratori, come nel corso di Architetture Parallele e Distribuite). Questa scelta conduce al così detto modello di architettura a programma memorizzato, o modello di Von Neumann: il programma assembler da eseguire (da interpretare da parte del Processore) risiede in una memoria accessibile al Processore, detta Memoria Principale del calcolatore. Questo comporta che le istruzioni del programma assembler, rappresentate in binario (come stringhe di bit), siano memorizzate come parole di memoria, che possono essere lette dal Processore nel giusto ordine; cioè, è il Processore stesso (il suo microprogramma) che reperisce una istruzione alla volta dalla memoria e provvede alla sua esecuzione (interpretazione). Più in dettaglio: i) una volta letta dalla memoria, ogni istruzione verrà riconosciuta univocamente, attraverso un suo campo Codice Operativo, in modo che il microprogramma del Processore possa svolgere quelle azioni che sono necessarie per l esecuzione dell istruzione stessa; ii) iii) completata una istruzione, il Processore deve poter individuare l istruzione successiva. A questo scopo il Processore dispone di un registro, detto Contatore Istruzioni (IC), che contiene l indirizzo dell istruzione da eseguire; il contenuto di IC verrà modificato, durante il (alla fine del) microprogramma di ogni istruzione, in modo da portarlo ad assumere il valore dell indirizzo della prossima istruzione da leggere dalla memoria; tra le azioni da effettuare durante l interpretazione di una istruzione, ci possono essere anche letture o scritture di dati del programma residenti nella Memoria Dati. In una architettura a programma memorizzato, questa viene fatta coincidere logicamente con la Memoria Principale. Ne consegue che, nel modello di Von Neumann, concettualmente non c è distinzione tra istruzioni e dati: in effetti, entrambe le informazioni sono dati utilizzati dal microprogramma-interprete e reperiti in una memoria accessibile al Processore; un particolare tipo di dato è l istruzione, così come in una unità specializzata (vedi Cap. III della Dispensa) i messaggi in ingresso contengono informazioni sia sull operazione esterna che sui dati ad essa associati. L architettura firmware di un elaboratore general-purpose assume allora la forma schematica della fig. 1 Memoria Principale (M) richieste IC Processore (P) risposte Registri Generali (RG) Sottosistema di Ingresso / Uscita (I/O) Memorie di massa (dischi, ecc.) Monitor Tastiere, Mouse Stampanti Interfacce di rete Fig. 1 Note sulla fig. 1: (1) richieste: richieste di accesso alla memoria da parte di P; possono essere richieste di lettura di una istruzione all indirizzo IC, oppure richieste di lettura o di scrittura di una dato all indirizzo generato durante l esecuzione del microprogramma; (2) risposte: parole lette dalla memoria (istruzioni o dati) in risposta ad una richiesta di P, più informazioni sull esito dell accesso;

5 5 (3) nel Processore, oltre al registro contatore istruzioni IC (fondamentale in qualunque realizzazione del modello di Von Neumann), sono indicati i Registri Generali, cioè registri visibili a livello assembler (riferiti esplicitamente dalle istruzioni assembler), che svolgono un ruolo importante agli effetti delle ottimizzazioni introdotte dal compilatore. Ovviamente, come accade nel progetto di ogni unità di elaborazione, nell unità P saranno presenti altri registri, visibili esclusivamente a livello firmware. Il formato di una generica istruzione assembler è codificato come una stringa di bit nella quale si riconoscono campi corrispondenti alle seguenti informazioni (alcune possono essere implicite a seconda del Codice Operativo): Codice Operativo riferimenti (indirizzi ) ad operandi e risultati informazioni su come individuare l istruzione successiva. Tale formato può essere codificato mediante una singola parola oppure mediante più parole consecutive (eventualmente in numero variabile a seconda della classe di istruzione); nel secondo caso, il Processore provvede a leggere dalla memoria il numero corrispondente di parole. Ad alto livello, il microprogramma del Processore (interprete del linguaggio assembler, e quindi interprete del programma eseguibile) assume la forma seguente nel modello di Von Neumann: while true { chiamata dell istruzione: lettura dell istruzione dalla memoria all indirizzo IC; } decodifica dell istruzione: riconoscimento dell istruzione letta mediante il campo Codice Operativo; esecuzione dell istruzione: per ogni Codice Operativo verranno svolte azioni diverse, incluse eventuali letture e/o scritture di dati dalla memoria e/o dai Registri Generali; aggiornamento del contatore istruzioni IC; test di interruzioni: ascolto di eventuali segnalazioni da parte del sottosistema di I/O Inizialmente, IC assume il valore dell indirizzo della prima istruzione eseguibile. 3. I livelli assembler e firmware di un calcolatore general-purpose Nel Cap. V della Dispensa è introdotto un set di istruzioni assembler di tipo Risc, e sono studiate regole di compilazione di programmi. L esempio della sez. 1, per spiegare la differenza tra compilatore ed interprete, è un classico esercizio del Cap. V, che mostra come l uso opportuno dei registri generali permetta di introdurre alcune importanti ottimizzazioni nel codice eseguibile. Nello stesso Cap. V, e attraverso esercizi (Cap. VII, Raccolta 5), sono esaminate diverse alternative nella definizione del linguaggio assembler, sia di tipo Risc che Cisc. Uno schema di Processore capace di interpretare il set di istruzioni assembler del Cap. V è studiato nel Cap. VII. Importante, in questo capitolo, è anche la definizione dei metodi per la valutazione delle prestazioni sulla base delle caratteristiche dell architettura firmware e delle caratteristiche dei programmi. Nel Cap. VIII è studiata una importante soluzione per aumentare le prestazioni di un calcolatore, e cioè la memoria cache. Questa parte del corso permette di esemplificare una importante classe di ottimizzazioni a tempo di compilazione: per una migliore efficienza nello sfruttamento della memoria cache, si può pensare che il compilatore effettui una analisi del programma per individuare casi in cui sia applicabile la tecnica del prefetching dei blocchi (Cap. VIII, sez Memoria virtuale e spazio di indirizzamento Quello finora preso in considerazione è ancora uno schema semplificato dell architettura, a causa di diversi aspetti legati alle caratteristiche di livelli superiori del sistema. In particolare, è importante il concetto di memoria virtuale e le conseguenze che tale concetto ha sulla compilazione e sull architettura firmware. Nelle Dispense del corso, questo

6 6 argomento è trattato per una parte minimale nel Cap. V, ed in modo più sostanziale nel Cap. VI, sez. 2, nel Cap. VII, sez. 1.1, e nel Cap. VIII, sez. 1. Qui di seguito verrà dato un sommario degli aspetti legati a questo importante argomento, in modo che lo studente possa meglio legare tra loro le parti di materiale didattico: 1. gli indirizzi generati da ogni programma non sono direttamente indirizzi di memoria principale (indirizzi fisici), bensì indirizzi logici, cioè indirizzi riferiti ad una astrazione della memoria del programma, detta memoria virtuale. Questa può essere vista come un array unidimensionale, con indici (indirizzi logici) a partire da zero fino al massimo necessario per rappresentare il programma o fino al massimo consentito dall ampiezza dell indirizzo logico in bit (ad esempio, per una macchina a 32 bit e con indirizzamento alla parola, la massima ampiezza della memoria virtuale di ogni programma è 4G parole). Ad esempio, le istruzioni del programma iniziano dall indirizzo logico zero; dopo la zona della memoria virtuale occupata da istruzioni segue la zona occupata dai dati. L insieme degli indirizzi logici di un programma è detto spazio logico di indirizzamento di quel programma; 2. il codice eseguibile del programma, generato dal compilatore, è quindi riferito alla memoria virtuale. Il Processore genera indirizzi logici sia per le istruzioni che per i dati; 3. il risultato della compilazione è un file binario ( file oggetto ) che, come ogni file, viene conservato permanentemente in memoria secondaria e che, in tempi successivi qualsiasi, può venire utilizzato per eseguire il programma; 4. quando viene eseguito, il programma viene allocato in una zona della memoria principale, la cui ampiezza ed i cui indirizzi non coincidono (tranne casi particolari) con quelli della memoria virtuale del programma. In generale, per poter sfruttare convenientemente la risorsa memoria principale, istante per istante ogni programma non è interamente allocato in memoria principale, né la parte allocata è memorizzata ad indirizzi contigui. La memoria principale viene allocata dinamicamente ad ogni programma, contando sul fatto che una copia intera, ed integra, del programma è sempre presente in memoria secondaria; 5. quando un programma viene allocato (o riallocato) in memoria principale, viene stabilita una corrispondenza tra gli indirizzi logici della parte allocata e gli indirizzi fisici in cui viene allocata. Questa funzione, detta funzione di rilocazione o di traduzione dell indirizzo, viene di norma implementata come una tabella associata al programma (Tabella di Rilocazione), che fa parte essa stessa della memoria virtuale ed è allocata essa stessa in memoria principale; 6. la funzione viene aggiornata (dalla funzionalità del sistema operativo relativa alla gestione della memoria principale) ogni volta che l allocazione del programma viene modificata. Ad esempio, in un certo istante un programma in esecuzione può avere bisogno di informazioni che non sono attualmente allocate in memoria principale. Queste verranno copiate da memoria secondaria a memoria principale. In generale, le nuove informazioni andranno a sostituirne altre meno urgenti (dello stesso programma o di altri programmi); se le informazioni sostituite sono state nel frattempo modificate (scritture in variabili), i loro valori verranno ricopiati da memoria principale nelle posizioni corrispondenti della memoria secondaria. Questi spostamenti (riallocazioni) comportano opportune modifiche della Tabella di Rilocazione del programma (dei programmi). Si noti che il file eseguibile, presente in memoria secondaria, è sempre una immagine affidabile del programma; 7. la traduzione dell indirizzo deve essere effettuata in modo molto efficiente (non più di un ciclo di clock del Processore), e quindi l accesso alla Tabella di Rilocazione viene effettuata con opportune soluzioni hardwarefirmware delegate ad una unità interposta tra il Processore e la memoria virtuale (Memory Management Unit, o MMU). Quanto finora sintetizzato ha importanti conseguenze sulla compilazione e sull esecuzione di programmi. Vediamone alcune Inizializzazione di variabili Il compilatore, durante la traduzione di un programma, sceglie gli indirizzi logici di istruzioni e dati, e quindi configura lo spazio di indirizzamento logico, cioè lo spazio occupato dalla memoria virtuale di quel programma. Nel far questo, il compilatore può assegnare valori iniziali a variabili appartenente alla parte dati della memoria virtuale, oltre che valori iniziali a registri generali. Ad altre informazioni, che non hanno un valore iniziale, verrà comunque riservato spazio in memoria virtuale, senza prevederne un contenuto specifico. Il file eseguibile contiene quindi informazioni inizializzate (tutte le istruzioni, alcuni dati in memoria, alcuni registri generali) e non inizializzate. Quando il (una parte del) programma verrà caricato in memoria per essere eseguito, automaticamente verranno inizializzate le locazioni di memoria principale nelle quali sono allocate istruzioni e dati (la parte delle istruzioni e dei dati allocata in memoria principale).

7 Trasferimenti di ingresso-uscita Un altro con concetto molto importante è legato all impatto che la memoria virtuale ha sull implementazione dei traferimenti di ingresso-uscita. L implementazione, detta Memory Mapped I/O, che viene di seguito sintetizzata, si trova nel Cap. VI, sez. 3, Cap. VII, sez. 1.2, e Cap. IX, sez Si consideri il seguente esempio: un programma che opera su un array A di N interi, assegna agli elementi di A i valori iniziali prelevandoli da un dispositivo di I/O (tastiera, disco, rete, ). Invece di introdurre nel programma complesse e intricate codice sequenze di istruzioni dipendenti dalla natura del dispositivo, si può più semplicemente ragionare come segue: a) qualunque informazione presente nel sistema, incluso il sottosistema di I/O, viene vista come una informazione nella memoria virtuale del programma che deve utilizzare tale informazione. Questo è vero non solo per le informazioni che verranno allocate in memoria principale, ma anche per quelle trasferite dai/verso i dispositivi di I/O; b) ogni unità di I/O viene vista come se fosse un modulo di memoria fisica: la memoria principale contiene quindi non solo il modulo (i moduli) della parte indicata come memoria principale in senso stretto, ma anche tutte le memorie di I/O. In effetti, questa astrazione è molto vicina la vero: le unità di I/O contengono una loro memoria fisica (anche molto grande, ad esempio, qualche Kilo fino a qualche centinaio di Mega), realizzata come complesso di RAM, ROM, registri e interfacce; c) il programma di cui sopra può essere scritto come segue: for (i = 0; i < N; i++) A[i] = B[i]; dove B[N] è un array di interi appartenente alla memoria virtuale del programma, ma allocato nella memoria fisica di una qualche unità di I/O. Durante l esecuzione dell istruzione (LOAD) per trasferire il valore del generico B[i] in un registro generale, la traduzione dell indirizzo logico di B[i] produrrà un indirizzo fisico che non è relativo alla memoria principale, bensì a quella specifica memoria di I/O. Sarà compito della MMU (si veda la fig. 2 del Cap. VII, sez. 1) instradare opportunamente la richiesta di accesso in memoria, attendere dall unità di I/O il risultato dell accesso e ritornarlo al Processore; d) la funzione di traduzione degli indirizzi, relativi a dati allocati nello spazio di I/O (come l array B nell esempio), è prevista staticamente in base ad informazioni che il compilatore ha sulla configurazione del sottosistema di I/O ed in particolare sulle memorie di I/O Caricamento ed esecuzione di un programma Si veda Cap. V, sez. 3.4 e 4.10, Cap. VI, sez e sez Di seguito è riportata la sintesi di questo concetto: ad ogni programma (processo) è associato un descrittore di processo (PCB) contenente varie informazioni di utilità durante la vita del programma stesso, in particolare: immagine dei valori dei registri generali, immagine del valore del contatore istruzioni, immagine della Tabella di Rilocazione, ed altre informazioni; il PCB fa parte della memoria virtuale del programma, ed è quindi inizializzato a tempo di compilazione. Ciò significa che il file eseguibile contiene, nella parte PCB, i valori iniziali di IC e dei registri generali; quando viene lanciato il comando di esecuzione di un certo programma, il gestore della memoria principale (sistema operativo) provvede a individuare (se possibile) una parte della memoria principale in cui allocare una porzione del programma ( working set del programma, vedi Cap. VIII, sez. 1.2). Tale porzione, che deve includere comunque il PCB, viene quindi copiata da memoria secondaria a memoria principale. Il PCB viene concatenato alla lista dei programmi eseguibili (Lista dei Processi Pronti, Cap. VI, sez. 1.3). Quando il Processore si rende disponibile, dal PCB primo in lista vengono copiate le immagini dei registri generali e del contatore istruzioni nei registri corrispondenti del Processore. Questo rende quindi possibile l inizializzazione dei registri RG e IC mediante una sequenza di istruzioni assembler. Se l ultima istruzione (START_PROCESS: vedi Cap. V, sez. 2.7) quella che provvede a caricare IC ed a fornire alla MMU le informazioni minime sulla nuova Tabella di Rilocazione, la prossima istruzione eseguita sarà la prima istruzione da cui deve iniziare (o riprendere) l esecuzione del nuovo programma. In termini di sistema operativo, la funzionalità ora vista corrisponde alla così detta creazione di un processo.

8 8 5. Processi cooperanti 5.1. Dai programmi ai processi Per svariate ragioni (costo, efficienza, messa a disposizione di servizi, gestione di risorse), in un sistema di elaborazione general-purpose coesistono, istante per istante, più programmi, alcuni applicativi (utenti), altri di sistema (sistema operativo), altri ancora per lo sviluppo di applicazioni (compilatori, debugger, monitor, editor, interfacce grafiche, ecc). La convenienza di questa visione si può vedere considerando il ciclo di vita di un generico programma applicativo; ad esempio: quando ne viene chiesta la compilazione, il sistema sarà generalmente già occupato ad eseguire altri programmi; quando ne viene chiesta l esecuzione, come sintetizzato nella sez. 4, l allocazione dinamica delle risorse (memoria principale) viene effettuata da altri programmi (di sistema) che coesistono con una o più applicazioni correnti; quando, durante l esecuzione, il programma rileva la mancanza di risorse necessarie (ad esempio, fault di pagina della memoria virtuale), occorre che esso cooperi con programmi di sistema opportuni (gestore della memoria); analogamente se, durante l esecuzione, un programma necessita di accedere a risorse gestite dal sistema (ad esempio, files). Questa coesistenza, detta anche multiprogrammazione (o altri termini), è implementata anche in un calcolatore con un solo processore. Sono i tempi morti che si verificano frequentemente durante l elaborazione di un programma a far sì che possano subentrare, al suo posto nell utilizzo della risorsa Processore, altri programmi. Ovviamente, avendo più Processori (più CPU), l occasione di dar luogo a multiprogrammazione è ancora più evidente: nello stesso istante, tanti programmi per quante sono le CPU sono effettivamente in esecuzione; cioè, si ha parallelismo a livello di programmi. Avendo invece un unico Processore, la multiprogrammazione contribuisce a sfruttare meglio le risorse del sistema (Processore e memoria principale, in primis), dando l illusione, su un certo arco di tempo, che più programmi siano in esecuzione contemporaneamente: in realtà non si ha vero parallelismo, ma parallelismo simulato. Il concetto di processo sta a significare un programma capace di essere eseguito contemporaneamente ad altri, ed in generale di cooperare con altri, dove la contemporaneità può essere effettiva (parallelismo in senso stretto) o simulata (in questo caso si usa il termine concorrenza, più generale di parallelismo). Il concetto di processo è quindi un caso particolare del concetto di modulo di elaborazione (Cap. I, sez. 2), visto ai livelli delle applicazioni e del sistema operativo, così come lo sono le unità di elaborazione a livello firmware. Così come le unità, anche i processi si possono comporre affinché cooperino ad un fine comune (una applicazione). A livello dei processi, un sistema di elaborazione va quindi visto come una collezione (in generale dinamica) di processi cooperanti. Una tipica situazione è quella in cui si distinguono due sottoinsiemi di processi: processi di sistema (operativo): sono processi che esistono permanentemente nel sistema, e che sono delegati alla gestione di risorse e servizi nei confronti di richieste delle applicazioni, ad esempio gestione della memoria principale, gestione della memoria secondaria, gestione dei file, gestione di dispositivi periferici (driver), gestione delle applicazioni (shell). Oltre che con le applicazioni, i processi di sistema cooperano tra loro: ad esempio, il processo shell coopera almeno con il gestore della memoria principale e con il gestore dei file, il gestore della memoria principale può cooperare con il gestore dei file e con il driver del disco, ecc. In sintesi, il sistema operativo può esser visto come un programma parallelo; processi applicativi, che derivano dalla compilazione e dalla richiesta di esecuzione di programmi applicativi. Questi processi, in generale, nascono e muoiono. Se si tratta di processi derivati da programmi sequenziali, i processi applicativi non cooperano direttamente tra loro, ma solo con i processi di sistema. È però possibile avere anche programmi paralleli a livello di applicazioni, pur di adottare opportuni linguaggi ed ambienti di programmazione per il calcolo parallelo e distribuito: in questo caso, una applicazione è costituita da più processi tra loro cooperanti (oltre che cooperare con i processi di sistema) Processi cooperanti a scambio di messaggi Un modo elegante (non l unico, ma del tutto reale e molto frequente) di vedere la cooperazione tra processi è quella di considerare, come modalità di cooperazione, lo scambio di messaggi nel modello ad ambiente locale (Cap. I, sez. 3); in altri termini, ragionare come a livello di unità: la composizione di più processi, ognuno con il proprio ambiente locale, si ottiene facendoli comunicare attraverso canali di comunicazione.

9 9 Si consideri il seguente esempio: un processo applicativo (APPL), sequenziale al suo interno, ha bisogno di accedere a certi file, e quindi di cooperare con il processo gestire dei file (G_FILE), e di inviare dati ad una stampante, e quindi di cooperare con il driver della stampante (D_PRINTER); inoltre, come tutti i processi, può aver bisogno di cooperare con il processo gestore della memoria principale (G_MEM), in seguito ad eventi che attivano l allocazione dinamica della memoria principale stessa. A loro volta, i processi di sistam coinvolti hanno bisogno di cooperare con altri, come ad esempio il driver del disco (D_DISC). La configurazione di processi e canali in gioco può essere quella mostrata in Fig.2: G_MEM L APPL G_FILE D_PRINTER D_DISC Fig. 2 Supponiamo che, in un certo punto del programma, APPL debba leggere in file di nome MY_FILE, e sia BUF la variabile locale in cui copiare il valore del file. Nel modello di Fig. 2, la compilazione del comando di lettura-file consisterà in un comando per inviare al processo G_FILE un messaggio contenente l identificatore dell operazione richiesta (read_file) e il nome del file da leggere (MY_FILE). Sarà interamente compito del processo G_FILE effettuare tutte le azioni per controllare la legittimità di APPL ad accedere in lettura a quel certo file, per leggere fisicamente il file da disco, interagendo allo scopo con D_DISCO, e quindi inviare il valore del file ad APPL con una indicazione di esito (se negativo, il valore del file non è significativo). APPL, da parte sua, dopo aver inviato a G_FILE il messaggio di lettura-file, ed eventualmente avere eseguito altre azioni indipendenti dal valore del file, attende di ricevere un messaggio da G_FILE contenente appunto l esito e l eventuale valore del file che assegnerà alla variabile BUF. Supponiamo di disporre di un formalismo (linguaggio di programmazione concorrente) in cui sia possibile scrivere processi mediante gli usuali comandi sequenziali ed, in più, mediante i comandi per scambiare messaggi con altri processi (si veda Cap. I, sez. 3.4). Una sintassi di tali comandi può essere: send (identificatore di canale, valore) receive (identificatore di canale, identificatore di variabile targa) Oltre a questi comandi, normalmente ne sono presenti altri, in particolare ne occorre almeno un altro per il controllo del nondeterminismo nelle comunicazioni (Cap. V, sez. 3.5). I canali, con tipo, sono contraddistinti da un identificatore unico. I valori di messaggi e le variabili targa possono essere strutturati come tuple. Nel nostro caso, una possibile compilazione di APPL può essere la seguente:

10 10 C1 send (CH_FILE_OUT, (read_file, MY_FILE)) C2 receive (CH_FILE_IN, (esito_file, BUF) test di esito_file e gestione dell eventuale eccezione C3 (da qui in poi il codice è eseguito solo se esito_file = OK) send (CH_PRINTER_OUT, RESULT) C2 receive (CH_FILE_IN, esito_printer) test di esito_printer e gestione dell eventuale eccezione C4 C1, C2, C3, C4 sono sequenze di istruzioni assembler relative alla compilazione dell elaborazione propria di APPL. RESULT è una struttura dati il cui valore deve essere stampato. CH_FILE_OUT, CH_FILE_IN, CH_PRINTER_OUT, CH_PRINTER_IN sono nomi mnemonici di canali che, in realtà, consisteranno in identificatori unici interi. I comandi send e receive vanno intesi come sostituiti da sequenze generali di istruzioni che implementano le primitive di invio e di ricezione di messaggi: cioè, queste sequenze sono l interprete dai comandi send e receive. Equivalentemente, nei punti in cui compaiono i comandi send e receive il compilatore può avere inserito chiamate alle procedure che consistono nel suddetto interprete. Infine, si noti come che la strutturazione a processi comunicanti e la strutturazione ad oggetti: nel primo caso, le interfacce, mediante le quali viene invocato un metodo di una istanza di classe, corrispondono ai canali di comunicazione. Ad esempio, il canale CH_FILE_OUT è l entità attraverso la quale un processo applicativo può invocare la funzionalità di lettura/scrittura/creazione di file; per avere una analogia ancora più forte, avremmo potuto introdurre più canali in ingresso a G_FILE, ognuno corrispondente ad una specifica operazione, eliminando dal messaggio la presenza del parametro operazione Sistema operativo e compilazione di programmi applicativi Quanto esemplificato nella sezione precedente ha carattere di generalità: la compilazione di un programma applicativo produce un processo che contiene tutte le chiamate al sistema operativo, cioè invocazioni all interprete delle funzionalità di gestione delle risorse necessarie al programma stesso. L interprete è il sistema operativo stesso. Consideriamo un sistema operativo a nucleo minimo, nel quale tutta la gestione delle risorse (eccetto dei processori) è effettuata da appositi processi (gestori dello spazio di memoria principale e dello spazio di memoria secondaria, file system, driver delle unità di I/O). Se il linguaggio concorrente di sistema è a scambio di messaggi, i processi di sistema prevedono canali di comunicazione (oltre che con altri processi di sistema) con un certo numero massimo di processi applicativi. Questo permette di realizzare a tempo di compilazione, in modo agevole e modulare, l aggancio tra processi applicativi e processi di sistema. Ad esempio, se un programma applicativo contiene comandi per leggere/scrivere certi file, o per stampare certi dati, il processo derivante dalla sua compilazione contiene, in corrispondenza di tali comandi, chiamate delle procedure send e/o receive necessarie per effettuare richieste ai processi gestori (nell esempio, file system, driver della stampante) e ricevere eventuali risposte, come schematizzato in Fig. 3: I canali sono tutti identificati da interi noti a priori e a disposizione del compilatore per produrre il codice dei comandi di invio e ricezione messaggi. Ad esempio, il compilatore sa che il canale CH_FILE_IN in ingresso al processi gestore dei file ha identificatore 37. Questo valore verrà utilizzato in tutti i comandi send corrispondenti alla richiesta di lettura file, qualunque sia il processo applicativo in cui tale comando è inserito (dal compilatore stesso); in questa visione, i canali sono in gran parte asimmetrici.

11 11 Processo applicativo Gestore memoria principale Gestore File (File System) Driver disco Driver stampante... Driver rete I/O disc I/O printer I/O net... Fig. 3 Allo stesso modo, ai canali d ingresso dei processi applicativi vengono assegnati, a compilazione, identificatori appartenenti ad un insieme di interi noto a priori. Si tenga conto che questa soluzione è corretta in quanto gli stessi processi applicativi sono contraddistinti da identificatori unici, e questi sono in numero limitato in quanto esiste un numero massimo di processi (ad esempio, 20000) che possono essere ammessi al sistema contemporaneamente; ogni volta che un processo applicativo termina, il suo identificatore verrà riutilizzato per contraddistinguere un processo creato successivamente. 6. Introduzione ai sistemi operativi: il nucleo Dopo l introduzione al concetto di processo e di processo cooperante della sez. 5, lo studente può passare allo studio del Cap. VI della Dispensa. In particolare nella sez. 1.3 si studia come implementare il concetto di processo, dando luogo al così detto nucleo del sistema operativo visto come supporto a tempo di esecuzione (cioè, l interprete) del linguaggio concorrente di sistema, ad esempio come interprete di un linguaggio sequenziale arricchito di comandi per la cooperazione a scambio di messaggi. Le sezioni che seguono servono da ulteriore chiarimento di quanto esposto nella sez. 1.3 del Cap. VI Scheduling a basso livello, architettura astratta e architetture concrete Consideriamo una computazione, ai livelli delle Applicazioni e del Sistema Operativo, costituita da un certo numero di processi cooperanti P 1, P 2,, P n. L architettura astratta che supporta l elaborazione di tale computazione è costituita da tanti processori virtuali, PV 1, PV 2,, PV n, per quanti sono i processi: il generico PV i è delegato all elaborazione di P i. Inoltre, supporremo che tale architettura astratta sia un multiprocessor a memoria condivisa, nel quale (come mostrato nella figura seguente) tutti i processori (CPU con propria memoria locale o cache) sono connessi ad una stessa memoria principale, nella quale sono allocate, in particolare, strutture dati condivise tra i processi, come le strutture dati di nucleo (Figura 4):

12 12 Memoria Principale Condivisa arbitro di memoria e comunicazione tra processori PV 1 PV i PV n Fig. 4 Con questa architettura astratta gli stati di avanzamento sono solo quelli di Esecuzione e di Attesa. Quest ultimo è di Attesa Attiva, in quanto, una volta che il generico P i attenda il verificarsi di un certo evento, PV i non ha alcun altro processo da eseguire e può solo essere sbloccato da una esplicita segnalazione da parte di un altro processore virtuale (in modo del tutto analogo a quanto avviene tra unità comunicanti a livello firmware). Il nucleo, ed in particolare la funzionalità di scheduling a basso livello, ha il compito di emulare l architettura astratta su una specifica architettura concreta. Quest ultima potrà essere ancora un multiprocessor, ma con un numero di processori minore di n o,come caso particolare, un uniprocessor. Per rendere possibile tale emulazione: agli stati di avanzamento viene aggiunto lo stato di Pronto (vedi Dispensa, Cap. VI, sez. 1.3): i descrittori (PCB) di tutti i processi in stato di pronto sono collegati da un unica Lista Pronti (nel caso più semplice con disciplina FIFO, più spesso con disciplina a priorità); lo stato di Attesa è ora di Attesa Passiva: il processore su cui veniva eseguito il processo che si sospende viene reso disponibile al primo processo in Lista Pronti. Questa modalità di attesa viene introdotta per ragioni di efficienza (miglior sfruttamento dei processori) e per ragioni di correttezza (se l architettura concreta è uniprocessor, non appena un processo si sospendesse in attesa di un evento che deve essere provocato da un altro processo, il sistema risulterebbe bloccato in eterno). L elaborazione della computazione a processi sull architettura concreta procede quindi con il meccanismo della multiprogrammazione, o interleaving: in un uniprocessor quei processi, che sarebbero eseguibili simultaneamente, vengono eseguiti in un qualsiasi ordine sull unico processore disponibile, sfruttando le transizioni di stato di avanzamento (concorrenza); in un multiprocessor si ha anche un certo parallelismo effettivo, ma viene ancora sfruttato l effetto concorrenza su ogni processore Interruzioni ed eccezioni Per il trattamento di questi eventi, che è parte integrante del nucleo, è necessario un minimo di supporto a livello firmware: si veda nelle Dispense il Cap. VI, sez. 2.5 e 3.2, e il Cap. VII, sez Prerilascio e quanti di tempo Nella sez del Cap. VI è indicato come il prerilascio di un processore si possa verificare in due occasioni distinte: i) un processo A in Attesa viene svegliato da un processo B ed A ha priorità maggiore di B (la priorità di un processo è indicata da un campo del proprio PCB): A passa direttamente in Esecuzione sul processore utilizzato da B, e B passa in stato di Pronto; ii) un processo A in Esecuzione passa in stato di Pronto per permettere al primo processo Pronto di passare in Esecuzione: questo meccanismo viene utilizzato nella gestione del processore a quanti di tempo (time sharing), in modo da bilanciare l utilizzazione del processore stesso da parte di processi lunghi, e/o con scarse occasioni di cooperazione con altri processi, e di processi corti, e/o con frequenti interazioni con altri processi.

13 13 Lo scheduling a quanti di tempo utilizza una apposita unità di I/O che funge da Timer: a distanza di un quanto di tempo (scandito da un certo numero di cicli di clock dell unità; ad esempio, circa un milione di cicli di clock per un quanto di tempo dell ordine del msec), tale unità invia una interruzione di fine quanto di tempo : il suo trattamento consiste nella sequenza di azioni per effettuare il prerilascio del processore. Il funzionamento a quanti di tempo, insieme al meccanismo delle interruzioni ed all ordine casuale con cui i processi si pongono in Lista Pronti, contribuisce a rendere ancora sostanzialmente impredicibile l ordine con il quale i processi utilizzano i processori in un funzionamento in multiprogrammazione o interleaving Indivisibilità Tutti problemi di sincronizzazione e consistenza di strutture dati condivise, che si possono verificare sull architettura astratta, si verificano anche su una qualunque architettura concreta. La soluzione di tali problemi sarà di volta in volta specifica dell architettura concreta considerata. Si consideri il seguente esempio: un processo A intende svegliare un processo B, e contemporaneamente un processo C intende svegliare un processo D. Nell architettura astratta A e C provano ad appendere alla Lista Pronti B e D rispettivamente: è evidente che queste due operazioni devono essere eseguite in modo mutuamente esclusivo (in un ordine qualsiasi, purchè una dopo l altra) in quanto, altrimenti, il valore finale della struttura dati Lista Pronti potrebbe risultare impredicibile. Occorre garantire che la sequenza di azioni per effettuare la fase di sveglia sia indivisibile, cioè che nessun altro processo effettui contemporaneamente, sulla stessa struttura dati, una sequenza di azioni incompatibile. Altri esempi di sequenze di azioni incompatibili se eseguite contemporaneamente, e dunque da rendere indivisibili, sono: la manipolazione del buffer, o di altri campi, di un canale di comunicazione da parte del processo mittente e del processo destinatario di comunicazioni; la manipolazione della Lista Pronti per eseguire una sveglia e per eseguire contemporaneamente una commutazione di contesto (a seconda della realizzazione della Lista Pronti). Nell architettura astratta il meccanismo per rendere indivisibili sequenze di operazioni, eseguite da processori virtuali distinti, utilizza la struttura di arbitraggio della memoria condivisa: un processore virtuale segnala all arbitro (mediante una apposita operazione di lock) che intende iniziare una sequenza indivisibile e, alla fine della sequenza, segnala all arbitro che la sequenza si è conclusa (unlock). Durante tutta la sequenza di accessi indivisibile, l arbitro non permette ad altri processori virtuali di accedere alla memoria o, almeno, alla specifica struttura dati sulla quale è in corso la sequenza indivisibile. Nell architettura uniprocessor il problema dell indivisibilità si presenta allo stesso modo, a causa dell impredicibilità con la quale avviene l utilizzazione del processore da parte dei processi eseguibili: come detto, tale impredicibilità è dovuta al meccanismo delle interruzioni, al meccanismo dello scheduling a quanti di tempo ed all ordine con cui i processi si pongono in Lista Pronti. Nell esempio in cui A vuole svegliare B e C vuole svegliare D, supponiamo che A sia in Esecuzione e C in Pronto e che, prima di aver concluso la sequenze di azioni per appendere il PCB di B alla Lista Pronti, A venga portato in stato di Pronto in seguito allo scadere del suo quanto di tempo oppure in seguito ad una qualunque altra interruzione che provochi un prerilascio. Se è proprio C ad entrare in Esecuzione, C si trova a lavorare sulla Lista Pronti lasciata da A in uno stato non consistente (il risultato finale probabilmente è che né B né D passeranno in stato di Pronto). Analoghe considerazioni valgono per tutti gli altri esempi. Nell architettura uniprocessor, per quanto ora detto il meccanismo per assicurare l indivisibilità consiste nella disabilitazione delle interruzioni. In una architettura multiprocessor concreta, oltre al meccanismo della disabilitazione delle interruzioni per ogni processore, deve anche essere adottata una tecnica, come quella descritta per l architettura astratta, basata su operazioni lock-unlock sulla memoria condivisa per impedire che più processori contemporaneamente effettuino sequenze incompatibili sulle stesse strutture dati. Durante tutto il tempo in cui ad un processore è impedito l accesso alla memoria, il processo da esso eseguito effettua dunque Attesa Attiva Spazi di indirizzamento Come discusso a più riprese, lo spazio di indirizzamento di un processo è l insieme di tutti i possibili indirizzi logici che il processo può generare trovandosi in stato di Esecuzione. Tale spazio comprende gli indirizzi per le seguenti informazioni: a) codice del programma;