La presentazione è in caricamento. Aspetta per favore

La presentazione è in caricamento. Aspetta per favore

Sistema Operativo Architettura degli elaboratori 1 - A. Memo 283 6 Sistema Operativo 6Generalità 6.1Classificazioni e definizioni 6.2Struttura generale.

Presentazioni simili


Presentazione sul tema: "Sistema Operativo Architettura degli elaboratori 1 - A. Memo 283 6 Sistema Operativo 6Generalità 6.1Classificazioni e definizioni 6.2Struttura generale."— Transcript della presentazione:

1 Sistema Operativo Architettura degli elaboratori 1 - A. Memo Sistema Operativo 6Generalità 6.1Classificazioni e definizioni 6.2Struttura generale 6.3La gestione dei processi 6.4La gestione della memoria 6.5La gestione dell’I/O 6.6File system e protezione 6.7Unix - Windows

2 Sistema Operativo Architettura degli elaboratori 1 - A. Memo Generalità le macchine astratte 1 livello 4 : Macchina programmatore livello 5 : Macchina utente livello 0 : Macchina digitale livello 1 : Macchina microprogramma Offre un insieme di istruzioni più strut- turate che agevolano l’accesso e l’uso delle risorse dei livelli 0 e 1. Spesso nasconde cosa c’è sotto o come fun- ziona. Il linguaggio utilizzato è quello del- le chiamate di sistema. E’ prettamente soft- ware e indispensabile. livello 2 : Macchina hardware livello 3 : Macchina Sistema Operativo

3 Sistema Operativo Architettura degli elaboratori 1 - A. Memo Generalità le macchine astratte 2 Obiettivi del Sistema Operativo (OS): l rendere il calcolatore più semplice da utilizzare l ottimizzare l’utilizzo delle risorse –il SO deve gestire la CPU, la memoria principale e quella secondaria, le periferiche di I/O in maniera efficiente, assicurandone l’accesso ai richiedenti e regolandone la condivisione l gestire l’esecuzione dei programmi utente

4 Sistema Operativo Architettura degli elaboratori 1 - A. Memo Classificazioni e definizioni storia 1 l i programmi venivano inseriti tramite interruttori binari frontali, o lettori di schede perforate l i dati venivano letti tramite led binari, testo stampato o schede perforate I SO nascono negli anni ‘50, con i primi calcolatori elettronici a programma memo- rizzato

5 Sistema Operativo Architettura degli elaboratori 1 - A. Memo Classificazioni e definizioni storia 2 l negli anni ‘60 si sviluppa il software, nascono compilatori per nuovi linguaggi e tool di sviluppo l il costo elevato e la lentezza delle periferiche (es. caricare un nuovo compilatore) inducono il lavoro a lotti (batch) gestito dall’operatore: un solo programma alla volta, dati compresi

6 Sistema Operativo Architettura degli elaboratori 1 - A. Memo Classificazioni e definizioni storia 3 (batch) l dai batch gestiti dall’operatore si passa al monitor residente (RM) [S.O.batch] –schedulatore sequenziale dei vari job control- lato da schede perforate l le operazioni di I/O sono troppo lente ( volte) [S.O. I/O off-line] –direzionare l’I/O verso memorie a nastro mediante sistemi intelligenti dedicati, e sovrap- posizione tra esecuzione e gestione I/O

7 Sistema Operativo Architettura degli elaboratori 1 - A. Memo Classificazioni e definizioni storia 4 (multiprogramming) l utilizzo del disco rigido come buffer di I/O molto capiente [S.O. spooling] –Simultaneus Peripheral Operation On-Line, è più veloce e ad accesso diretto rispetto al nastro l utilizzo del disco anche per i programmi [S.O. multi-programming] –precarico nel disco un insieme di programmi, appena il primo termina mando in esecuzione il secondo, e così via.

8 Sistema Operativo Architettura degli elaboratori 1 - A. Memo Classificazioni e definizioni storia 5 (time sharing) l multi-programming (segue) –se un programma richiede I/O, posso assegnarlo ad un esecutore meno importante, e continuare con un altro programma l inizialmente c’era grande interattività e poca efficienza, ora alta efficienza ma scarsa interattività: [SO time-sharing] –un quanto di tempo per utente, se lo scambio è frequente, l’utente potrebbe non accorgersene

9 Sistema Operativo Architettura degli elaboratori 1 - A. Memo Classificazioni e definizioni storia 6 (paralleli) l time-sharing (segue) –esecuzione concorrente di più programmi –condivisione della memoria –schemi di protezione e controllo delle risorse l più CPU nello stesso sistema [SO paralleli] –generalmente condividono memoria e I/O –simmetrici, tutte le CPU hanno il medesimo SO –asimmetrici, solo una CPU ha il SO

10 Sistema Operativo Architettura degli elaboratori 1 - A. Memo Classificazioni e definizioni storia 7 (distribuiti e di rete) l più sistemi utilizzano il medesimo SO [SO distribuiti] –di solito operano su memorie ed I/O distinti –ciascuno ha un’immagine coincidente del SO l più sistemi interconnessi [SO di rete] –finalizzati alla condivisione delle risorse ed alla comunicazione

11 Sistema Operativo Architettura degli elaboratori 1 - A. Memo Classificazioni e definizioni storia 8 (real time e PC) l gestione prioritaria degli eventi esterni rispetto alla loro elaborazione [SO real-time] –impiegati nei controlli di processo e nei calcolatori dedicati –nuclei spesso ridotti l SO per personal computer –in corrispondenza alla diminuzione dei costi –via via inglobano le prestazioni degli altri SO

12 Sistema Operativo Architettura degli elaboratori 1 - A. Memo Classificazioni e definizioni definizione di SO Definizione di SO: un Sistema Operativo è un insieme di programmi che assolvono al duplice compito di far vedere all’utente una macchina virtuale semplificata e di gestire in maniera ottimiz-zata le risorse del calcolatore

13 Sistema Operativo Architettura degli elaboratori 1 - A. Memo Classificazioni e definizioni componenti di un SO l interfaccia utente l gestore processi l gestore risorse –processore/i –memoria principale –memoria secondaria –dispositivi di I/O l file system l sicurezza e protezione

14 Sistema Operativo Architettura degli elaboratori 1 - A. Memo Classificazioni e definizioni definizioni di processo l un processo è l’insieme ordinato degli stati che il sistema assume durante l’esecuzione di un particolare programma o parte di esso, a partire da uno specifico stato iniziale oppure l un processo è l’insieme ordinato delle azioni (operazioni) che il sistema esegue durante lo svolgimento di un particolare programma o insieme di istruzioni

15 Sistema Operativo Architettura degli elaboratori 1 - A. Memo Classificazioni e definizioni caratteristiche dei processi l un programma può determinare più processi l in un sistema coesistono processi utente e processi di sistema l i processi vengono creati, sospesi o terminati l i processi devono poter comunicare tra loro e sincronizzarsi l i processi avanzano concorrentemente

16 Sistema Operativo Architettura degli elaboratori 1 - A. Memo Classificazioni e definizioni gestore dei processi l è il cuore del SO, viene detto anche kernel –deve cambiare di stato i processi, scegliendo quello o quelli da mandare in esecuzione (scheduling) e ponendo in attesa quelli che richiedono una risorsa occupata –deve assicurare a tutti i processi la possibilità di avanzare, senza privilegiarne o penalizzarne alcuno –assicurare un meccanismo di sincronizzazione tra i vari processi

17 Sistema Operativo Architettura degli elaboratori 1 - A. Memo Classificazioni e definizioni definizioni di risorsa l una risorsa è qualsiasi elemento di natura hardware o software condiviso dai processi, necessario alla loro creazione o al loro avanzamento l le risorse possono essere: –riutilizzabili o consumabili –pre-rilasciabili e non –a molteplicità unaria o multipla

18 Sistema Operativo Architettura degli elaboratori 1 - A. Memo Classificazioni e definizioni la risorsa processore l è l’unica risorsa (hardware o software) indispensabile per l’avanzamento di tutti i processi l a livello hardware può essere associato alla CPU l a livello software in un sistema mono- processore il SO può virtualizzarne molti

19 Sistema Operativo Architettura degli elaboratori 1 - A. Memo Classificazioni e definizioni la risorsa memoria principale l è una risorsa riutilizzabile, pre-rilasciabile a molteplicità unitaria se in scrittura, multipla se in lettura l il SO la condivide tra i vari processi, di volta in volta attribuendola e liberandola l la gestione della memoria principale risulta più veloce se viene effettuata a livello hardware

20 Sistema Operativo Architettura degli elaboratori 1 - A. Memo Classificazioni e definizioni la risorsa memoria secondaria l è una risorsa riutilizzabile, pre-rilasciabile a molteplicità unitaria se in scrittura, multipla se in lettura l il SO ne regola le richieste di accesso, e la può attribuire o recuperare parzialmente ai vari processi

21 Sistema Operativo Architettura degli elaboratori 1 - A. Memo Classificazioni e definizioni le risorse gestione dell’I/O l sono generalmente risorse riutilizzabili, a molteplicità unaria e non pre-rilasciabili l il SO ne virtualizza l’impiego nasconden- one le caratteristiche hardware e omoge- neizzandone il trattamento l il SO ne regola e condivide l’accesso, richiamando le relative routine proprietarie

22 Sistema Operativo Architettura degli elaboratori 1 - A. Memo Classificazioni e definizioni file system l il file system è la componente del SO che gestisce i file e le directory l il SO garantisce una visione logica della struttura fisica della memoria secondaria l il SO gestisce la creazione, la cancellazione e la modifica delle proprietà dei file

23 Sistema Operativo Architettura degli elaboratori 1 - A. Memo Classificazioni e definizioni l’interfaccia utente l è l’insieme delle modalità con cui l’utente può accedere ai servizi offerti dal SO l l’accesso per l’operatore è basato su un interprete dei comandi, che li acquisisce, li decodifica e li esegue l l’accesso per i programmi utente avviene tramite chiamate standard (system call e/o API)

24 Sistema Operativo Architettura degli elaboratori 1 - A. Memo Classificazioni e definizioni sicurezza e protezione l la sicurezza di un SO è la capacità di svolgere correttamente le sue funzioni anche in presenza di guasti (tolleranza ai guasti) o tentativi di effrazione (protezione e controllo degli accessi)

25 Sistema Operativo Architettura degli elaboratori 1 - A. Memo Struttura generale possibili architetture l S.O. monolitici l S.O. a livelli l S.O. a macchine virtuali l S.O. client server

26 Sistema Operativo Architettura degli elaboratori 1 - A. Memo Struttura generale sistemi operativi monolitici l insieme paritetico di tutte le componenti che possono richiamarsi li- beramente l paragonabile alla pro- grammazione spaghetti l esempi: MS-DOS ed il primo UNIX Periferica 1 prog. 1 prog. 2 MS DOSBIOS

27 Sistema Operativo Architettura degli elaboratori 1 - A. Memo Struttura generale sistemi operativi a livelli 1 l suddivisione delle funzionalità del SO in livelli, in modo che ogni componente di un livello possa utilizzare solo le funzioni offerte dal livello sottostante l assicurano modularità e facilità di controllo l non sempre la suddivisione a livelli è facile o definibile

28 Sistema Operativo Architettura degli elaboratori 1 - A. Memo Struttura generale sistemi operativi a livelli 2 nucleo risorse superisore kernel API applications device drivers OS/2 generale La tendenza attuale è di avere un numero contenuto di livelli e spostare più funzioni possibile verso l’alto.

29 Sistema Operativo Architettura degli elaboratori 1 - A. Memo Struttura generale sistemi operativi a macchine virtuali 1 l sviluppato in IBM nel ‘79, distingue tra multi-programmazione e interfacciamento alle risorse l sopra al livello hardware opera il Virtual Machine Monitor, che offre al livello superiore più macchine virtuali complete, ciascuna dotata del proprio livello hardware (virtuale) indipendente

30 Sistema Operativo Architettura degli elaboratori 1 - A. Memo Struttura generale sistemi operativi a macchine virtuali 2 VM/370 Virtual Machine Monitor Conversational Monitor System IBM/370 virtuale livello hardware reale VM/370 IBM Conversational Monitor System IBM/370 virtuale Conversational Monitor System IBM/370 virtuale system call I/O instr.

31 Sistema Operativo Architettura degli elaboratori 1 - A. Memo Struttura generale sistemi operativi client-server l la tendenza odierna è di avere un kernel minimo e di implementare tutte le altre funzioni nei processi utente l nel client-server il kernel trasferisce solo i messaggi tra i vari processi kernel processo client processo server file server processo client

32 Sistema Operativo Architettura degli elaboratori 1 - A. Memo Struttura generale caricamento del SO 1 Il SO può risiedere l permanentemente su ROM –controllori industriali e sistemi dedicati l su disco ed essere caricato all’accensione (bootstrap) –adatto a sistemi complessi o gestiti da più sistemi operativi

33 Sistema Operativo Architettura degli elaboratori 1 - A. Memo Struttura generale caricamento del SO 2 l all’accensione viene eseguito un piccolo programma presente in ROM (Initial Program Loader) che legge la routine di caricamento (OS Loader) presente in una zona predefinita del disco. l questa routine carica il modulo Real Time Executive del SO, che fornisce i principali servizi offerti dal SO

34 Sistema Operativo Architettura degli elaboratori 1 - A. Memo Struttura generale sistema operativo elementare 1 l analizziamo brevemente il nucleo di un SO uniprocessor multiprogramming con time sharing, organizzato a livelli: –supervisor, con funzione di verifica dei diritti e attribuzione delle risorse –gestione delle risorse, escluso il processore –nucleo o kernel, per la gestione dei processi

35 Sistema Operativo Architettura degli elaboratori 1 - A. Memo 317 PRONTO ESECUZIONE BLOCCATO crea() termina() dispatcher() time_out() signal() wait() livello supervisor livello kernel ATTIVATO TERMINATO

36 Sistema Operativo Architettura degli elaboratori 1 - A. Memo Struttura generale sistema operativo elementare 3 ATTIVATO il supervisore lo attiva, e richiama la system call (sc) per creare il nuovo PCB PRONTO il processo è pronto ad andare in esecuzione e rimane in attesa del suo turno ESECUZIONE al processo selezionato è stato attribuito il processore, e sta avanzando

37 Sistema Operativo Architettura degli elaboratori 1 - A. Memo Struttura generale sistema operativo elementare 4 BLOCCATO il processo è sospeso in attesa di una risorsa attualmente non disponibile TERMINATO il processo ha concluso regolarmente le sue operazioni e si predispone ad “uscire” dal SO

38 Sistema Operativo Architettura degli elaboratori 1 - A. Memo Struttura generale sistema operativo elementare 5 crea() immette un nuovo processo nel kernel, aggior- nando la ready-list, o lista dei processi pronti dispatcher() manda in esecuzione il primo processo della ready-list time_out() il processo in esecuzione esaurisce il quanto di tempo a sua disposizione e ritorna nella ready-list

39 Sistema Operativo Architettura degli elaboratori 1 - A. Memo Struttura generale sistema operativo elementare 6 wait() il processo richiede l’uso di una risorsa, e se questa è occupata il processo viene sospeso signal() il processo corrente ha liberato la risorsa attesa dal processo bloccato, che passa nella ready-list termina() il processo in esecuzione termina regolarmente il suo lavoro e rilascia il PCB

40 Sistema Operativo Architettura degli elaboratori 1 - A. Memo Struttura generale sistema operativo elementare 7 I compiti del livello kernel sono quindi: –gestire la transizione da PRONTO ad ESECUZIONE –gestire le interruzioni esterne causate da eventi di I/O o da situazioni critiche rilevate da altri processi o componenti del SO –fornire ai livelli superiori le primitive per la gestione dei processi (creazione, terminazione e sincronizzazione)

41 Sistema Operativo Architettura degli elaboratori 1 - A. Memo La gestione dei processi l definizione (vista in precedenza) l stati di un processo (visti in precedenza) l descrittore dei processi l schedulazione dei processi l operazioni sui processi l i thread (LWP) l Inter Process Comunications l deadlock

42 Sistema Operativo Architettura degli elaboratori 1 - A. Memo La gestione dei processi PCB l ogni processo è caratterizzato da un descrittore di processo (Process Control Block) composto da: –identificatore del processo –contesto interno della CPU (registri) –stato di avanzamento –priorità iniziale ed attuale –diritti di accesso alle risorse –processo padre ed eventali processi figli –puntatore alla lista delle risorse assegnate –puntatore alla coda messaggi in arrivo

43 Sistema Operativo Architettura degli elaboratori 1 - A. Memo La gestione dei processi passaggio tra processi l se in un sistema possono avanzare concorrentemente più processi, occorre un metodo per decidere quando passare da uno all’altro –scambio cooperativo (co-operative o non pre-emptive switching), in cui è il processo in esecuzione che decide quando passare il controllo al processo successivo [Win 3.1] –scambio a pre-rilascio in cui il processo in esecuzione viene scalzato o da un processo in attesa a priorità maggiore (priority pre-emptive switching) o quando ha esaurito il tempo a sua disposizione (time-sharing pre-emptive switching) [UNIX e Win NT]

44 Sistema Operativo Architettura degli elaboratori 1 - A. Memo La gestione dei processi schedulazione dei processi I processi possono essere schedulati l dalla ready list per mandarli in esecuzione, dispatcher, (short-term scheduler) l dalla job list, lista dei processi in attesa di attivazione (long-term scheduler) l dalle liste in coda alle risorse di I/O (gestore delle risorse)

45 Sistema Operativo Architettura degli elaboratori 1 - A. Memo La gestione dei processi dispatcher 1 l il dispatcher è lo schedulatore più critico in quanto viene richiamato ad ogni scambio l il dispatcher deve cambiare il contesto e ritornare il controllo all’utente l i criteri di valutazione di un dispatcher sono –percentuale di utilizzazione della CPU –numero di processi completati nell’unità di tempo –durata dell’attesa nella ready list

46 Sistema Operativo Architettura degli elaboratori 1 - A. Memo La gestione dei processi dispatcher 2 l la tecnica più semplice di gestione della ready list è la FCFS –il primo processo ad arrivare nella coda sarà il primo ad essere estratto per mandarlo in esecuzione, e vi rimarrà fino a che non chiede una risorsa o termina –ottimizza i tempi di scelta ed è facilmente implementabile, ma si blocca se un processo si blocca, non minimizza i tempi di attesa e attribuisce implicitamente priorità maggiore ad un tipo di processi

47 Sistema Operativo Architettura degli elaboratori 1 - A. Memo La gestione dei processi dispatcher 3 l Dati tre processi A, B e C con tempi di esecuzione rispettivamente 2, 5 e 10 mS, i tempi di attesa medi dipendono dall’ordine di esecuzione: A B Ct = 9/3 = 3 mS B C At = 20/3  6,6 mS B A Ct = 12/3  4 mS C A B t = 22/3  7,3 mS A C Bt = 14/3  4,6 mS C B At = 25/3  8,3 mS l l’attesa media minore si ha eseguendo prima quelli con tempi di esecuzione minori (SJF, short job first), o in pre-emption SRTF, shortest remaining- time first

48 Sistema Operativo Architettura degli elaboratori 1 - A. Memo La gestione dei processi dispatcher 4 l un processo è generalmente costituito da una sequenza di attività_CPU intervallate da attività_I/O l i processi si possono classificare in –CPU_bound se richiedono poche attività_CPU di durata molto lunga –I/O_bound se richiedono molte attività_CPU di breve durata intervallate da attività_I/O molto lunghe l la tecnica FCFS penalizza i processi I/O_bound

49 Sistema Operativo Architettura degli elaboratori 1 - A. Memo La gestione dei processi dispatcher 5 l le politiche SJF ed SRTF sono complesse ed onerose da implementare l si possono attribuire priorità diverse ai vari processi (SJF si può considerare a priorità in base al tempo di esecuzione) –i criteri di priorità influiscono le prestazioni –si possono minimizzare i tempi di attesa medi, ma penalizzare fortemente qualche processo (con il pre- emption si può arrivare anche al blocco)

50 Sistema Operativo Architettura degli elaboratori 1 - A. Memo La gestione dei processi dispatcher 6 l introducendo il concetto di time-sharing, dalla politica FCFS si deriva la tecnica round-robin l Dati tre processi A, B e C con tempi di esecuzione di 2, 5 e 10 mS ed un quanto di tempo di 2 mS: A B1B1 C1C1 B2B2 C2C2 B3B3 C3C3 C4C4 C5C5 il tempo medio di attesa vale (0+6+7)/3  4,3 mS + (9/3 =) 3 cambi di contesto (che devono essere rapidi)

51 Sistema Operativo Architettura degli elaboratori 1 - A. Memo La gestione dei processi dispatcher 7 l attribuendo ad ogni processo una propria priorità si ottiene la tecnica Multi-level Queue Scheduling –i processi vengono posti in code distinte, uno per ogni livello di priorità –ogni coda viene gestita con la propria politica –c’è una politica di scheduling tra le varie code –una semplice implementazione è la round-robin a due livelli: quelli CPU_bound ed I/O_bound

52 Sistema Operativo Architettura degli elaboratori 1 - A. Memo La gestione dei processi creazione di un processo 1 l il programmatore UNIX, per creare un pro- cesso, utilizza la funzione fork() delle API val fork() attiva un nuovo processo figlio simile al padre, ma con un proprio PID val = -1 operazione fork non riuscita = 0 identifica il processo figlio > 0 identifica il padre, e gli restituisce il PID del figlio generato

53 Sistema Operativo Architettura degli elaboratori 1 - A. Memo La gestione dei processi creazione di un processo 2 #include int main(void) { pid_t pid; pid = fork(); if (pid == -1) { fprintf(stderr, "fork() non riuscita\n"); exit(1); } if (pid == 0) { printf("Sono il figlio\n"); exit(0); } if (pid > 0) { printf("Sono il padre del figlio n.%d\n", pid); exit(0); } } /* si noti l’ordine casuale dei messaggi */

54 Sistema Operativo Architettura degli elaboratori 1 - A. Memo La gestione dei processi processi e thread modello a processi ogni processo ha il pro- prio spazio di indirizza- bilità schemi di sicurezza e protezione semplificati scambio di contesto oneroso heavy-weight process modello a thread il thread ha una parte di stato proprio contenuto ed una parte condivisa con tutti i thread dello stesso programma, risorsa o altro la creazione e lo scambio di contesto sono più snelle light-weight process

55 Sistema Operativo Architettura degli elaboratori 1 - A. Memo La gestione dei processi thread 1 l un thread può essere pensato come una sequenza di istruzioni finalizzate ad un compito elementare specifico l un processo generalmente è scomponibile in più thread l il passaggio da programma a processo/i viene effettuato dal SO l la scomposizione del programma in thread è compito del programmatore

56 Sistema Operativo Architettura degli elaboratori 1 - A. Memo La gestione dei processi thread 2 l lo stato interno di un processo è contraddistinto dai valori assunti dai registri della CPU e dalle informazioni presenti nell’area di stack del processo l un thread (o light process) è spesso visto come un processo il cui stato interno è contraddistinto da un numero inferiore di valori, al minimo il solo IP e lo stack contenente l’indirizzo di ritorno

57 6.3 La gestione dei processi thread 3 class Azione implements Nucleo { Object oggetto; Azione(Object a) { oggetto = a; } public void esegui() { // esegue qualcosa su oggetto } class Programma { static public void main(String args[]) { Object ogg_1 = new Object(); Nucleo Azione_1 = new Azione(ogg_1); Thread t1 = new Thread(Azione_1); Nucleo Azione_2 = new Azione(ogg_1); Thread t2 = new Thread(Azione_2); t1.esegui(); t2.esegui(); // e così via... }

58 Sistema Operativo Architettura degli elaboratori 1 - A. Memo La gestione dei processi thread 4 l un thread in Java è caratterizzato dai valori di tutti i registri della CPU e dalle variabili locali della procedura thread, e non dagli oggetti, che vengono assimilati a variabili globali l nei SO multi-threading lo scambio tra i vari thread avviene solo per termine o rilascio spontaneo del thread in esecuzione

59 Sistema Operativo Architettura degli elaboratori 1 - A. Memo La gestione dei processi avanzamento dei processi 1 I processi possono avanzare in maniera l sequenziale, nei sistemi uni-processore con un solo contatore di programma; tipico nei SO monolitici l parallela, nei sistemi multi-processore, per ottenere il massimo delle prestazioni ma con scarsa efficenza l alternata, nei sistemi uni-processore con più contatori di programma, SO a massima efficenza

60 Sistema Operativo Architettura degli elaboratori 1 - A. Memo La gestione dei processi avanzamento dei processi 2 A BC sequenziale A B C parallela A1A1 B C1C1 A2A2 C2C2 A3A3 alternata

61 Sistema Operativo Architettura degli elaboratori 1 - A. Memo La gestione dei processi avanzamento dei processi 3 l l’avanzamento parallelo e quello alternato comportano l’esecuzione concorrente (reale o simulata) dei processi l in tal modo si possono condividere le risorse, aumentare la velocità di esecuzione globale e implementare il software secondo tecniche modulari

62 Sistema Operativo Architettura degli elaboratori 1 - A. Memo La gestione dei processi avanzamento dei processi 4 L’avanzamento concorrente di più processi può portare a risultati indeterminati. Esempio: il processo P 1 è composto da 2 azioni sequenziali, A e B: (supponiamo A: x=0 e B: y= x+2) il processo P 2 è composto da 2 azioni sequenziali, C e D (supponiamo C: x=10 e D: y= x-1) Le possibili sequenze di un avanzamento concorrente sono: A B C D (x=10, y=9)C A B D (x=0, y=-1) A C D B (x=10, y=12) C A D B (x=0, y=2) A C B D (x=10, y=9) C D A B (x=0, y=2)

63 Sistema Operativo Architettura degli elaboratori 1 - A. Memo La gestione dei processi sincronizzazione dei processi 1 l se due processi non condividono lo stesso stato possono operare concorrentemente l se non soddisfano le condizione di Bernstein non possono operare concorrentemente l conviene limitare la non-concorrenza solo in quei punti in cui effettivamente viene condiviso lo stato, mediante utilizzo di segnali o primitive di sincronizzazione

64 Sistema Operativo Architettura degli elaboratori 1 - A. Memo La gestione dei processi sincronizzazione dei processi 2 l supponiamo che A e B siano due processi che hanno in comune la variabile X, e che inizialmente X valga 10 l il processo A deve incrementarla di 2 unità l il processo B deve decrementarla di 4 unità l entrambi accedono contemporaneamente ad X, vedono che vale 10: il processo A scrive in X il suo risultato (12), mentre B scrive il suo (6) l alla fine X vale o 12 o 6, in base a chi termina prima, ma il risultato corretto (8) non lo scriverà nessuno

65 Sistema Operativo Architettura degli elaboratori 1 - A. Memo La gestione dei processi sincronizzazione dei processi 3 l per evitare questo problema dobbiamo far si che i due processi accedano in maniera mu- tuamente esclusiva alla variabile condivisa l il metodo più semplice sembra essere quello di utilizzare una variabile lucchetto (flag) che indichi quando la variabile condivisa (X) è in uso ad un altro processo (è detta anche mutex, da mutual exclusion)

66 Sistema Operativo Architettura degli elaboratori 1 - A. Memo La gestione dei processi sincronizzazione dei processi 4 - il processo A avanza - // deve accedere ad X - test (flag == 0) ? - se SI // X è in uso ritorno al test //aspetto - altrimenti // X è libera flag = 0 // occupo X - uso la variabile X - flag = 1 // libero X - il processo B avanza - // deve accedere ad X - test (flag == 0) ? - se SI // X è in uso ritorno al test //aspetto - altrimenti // X è libera flag = 0 // occupo X - uso la variabile X - flag = 1 // libero X altro esempio: lock file di UNIX

67 Sistema Operativo Architettura degli elaboratori 1 - A. Memo La gestione dei processi sincronizzazione dei processi 5 Questa soluzione ha due problemi: l in time sharing non funziona perché il processo può essere interrotto dopo aver controllato la variabile flag, ma prima di averla modificata (sezione critica) l il processo in attesa consuma risorsa CPU (attesa attiva)

68 Sistema Operativo Architettura degli elaboratori 1 - A. Memo La gestione dei processi sincronizzazione dei processi 6 l per assicurare la mutua esclusione in sezione critica si possono adottare due tecniche: –disabilitare gli interrupt all’ingresso in sezione critica e riabilitarli in uscita: in tal modo nessuno potrà sospendere le attività del processo; è pericoloso perché si possono perdere interrupt importanti, non va bene nei sistemi multi- processor, è troppo generalizzato e penalizzante –ricorrere ad una sola istruzione in linguaggio macchina (atomicità del comando) che acquisisca il valore di una variabile e ne forzi successi-vamente il valore ad 1 (istruzione test-and-set) (o con analoga xchg)

69 Sistema Operativo Architettura degli elaboratori 1 - A. Memo La gestione dei processi sincronizzazione dei processi 7 ancora: TSL reg,flag CMP reg,0 JNZ ancora // sezione critica MOV flag,0 flag a 0 indica risorsa disponibile, ad 1 indica risorsa già in uso. MOV reg,1 ancora: XCHG reg,flag CMP reg,0 JNZ ancora // sezione critica MOV flag,0 TSL reg,flag legge il valore di flag, lo pone nel registro reg, e poi porta flag a 1 XCHG reg,flag scambia i valori di flag con reg

70 Sistema Operativo Architettura degli elaboratori 1 - A. Memo La gestione dei processi sincronizzazione dei processi 8 l per evitare di dover programmare in LM, si utilizzano due primitive e la variabile semaforo: –il semaforo utilizza una variabile globale intera S che non può essere utilizzata direttamente, ma solo tramite due primitive pubbliche atomiche wait() e signal() ; per S>0 la risorsa è accessibile, inizial- mente S=1 void wait (int S) { while (S<=0)do; S --; } void signal (int S) { S ++; }

71 Sistema Operativo Architettura degli elaboratori 1 - A. Memo La gestione dei processi sincronizzazione dei processi 9 Se un processo vuole accedere alla risorsa R comune, regolata dalla variabile semaforo sem: processo { // avanzamento wait(sem); // usa risorsa R signal(sem); // avanzamento } wait(s) viene usata per richiedere l’accesso al- la risorsa, e signal(s) per rilasciare la risorsa

72 Sistema Operativo Architettura degli elaboratori 1 - A. Memo La gestione dei processi sincronizzazione dei processi 10 Se il processo A vuole sincronizzarsi con B, ed essere sicuro di avanzare solo quando B ha già raggiunto un certo punto (all’inizio sem=0) : processo A { // avanzamento wait(sem); // avanzamento } processo B { // avanzamento signal(sem); // avanzamento }

73 Sistema Operativo Architettura degli elaboratori 1 - A. Memo La gestione dei processi sincronizzazione dei processi 11 l Per evitare di avere attesa attiva, la funzione wait() può bloccare il processo che trova il semaforo occupato, e la funzione signal() può recuperare da una lista FIFO i processi in attesa (se ce ne sono) l Per assicurare l’atomicità di wait() e signal(), si devono disabilitare le interruzioni durante l’esecuzione delle due funzioni l Se il semaforo può assumere solo due valori numerici (0 ed 1) lo si chiama semaforo binario, altrimenti è un semaforo a contatore

74 Sistema Operativo Architettura degli elaboratori 1 - A. Memo La gestione dei processi sincronizzazione dei processi 12 void wait(struct sem){ sem.valore -- ; if (sem.valore < 0){ add (sem.lista, coda); sleep(chiamante); } void signal(struct sem){ sem.valore ++ ; if (sem.valore < 0) wakeup(estrai(coda)); } ora il semaforo è una struttura com- posta da un campo intero valore e da un campo lista con tutti i processi in attesa su quel semaforo

75 Sistema Operativo Architettura degli elaboratori 1 - A. Memo La gestione dei processi sincronizzazione dei processi 13 l per offrire strumenti di sincronizzazione ac- cessibili a linguaggi più astratti, sono stati introdotti i monitors –contengono sia la struttura dati, non accessibile dall’esterno, che le funzioni per gestirla (analoghi agli oggetti) –includono anche la coda dei processi in attesa –assicurano la mutua esclusione

76 Sistema Operativo Architettura degli elaboratori 1 - A. Memo La gestione dei processi InterProcess Communication 1 l adesso che abbiamo stabilito come possiamo condividere l’accesso ad una risorsa, e quindi anche alla memoria, vediamo quali strumenti possono utilizzare i processi per comunicare tra loro: l pipe (condotto) l stream (flusso) l socket (porta) l signal (messaggio)

77 Sistema Operativo Architettura degli elaboratori 1 - A. Memo La gestione dei processi InterProcess Communication 2 l il pipe è come un canale (buffer) uni- direzionale tra due processi: al suo ingresso un processo può scrivere informazioni ed alla sua uscita un altro processo le può leggere –un pipe può essere non identificabile, se condiviso tra processo padre e figlio –un pipe è identificabile se ha un ID che lo contraddistingue, e viene utilizzato da processi tra loro indipendenti, solo tramite il suo ID

78 Sistema Operativo Architettura degli elaboratori 1 - A. Memo La gestione dei processi InterProcess Communication 3 l uno stream è analogo al pipe, ma trasferisce informazioni strutturate l un socket rappresenta una porta di comuni- cazione tra due processi l il messaggio è il sistema più diretto per far interagire due processi, ed è l’unico che opera correttamente in ambienti a memoria non condivisa

79 Sistema Operativo Architettura degli elaboratori 1 - A. Memo La gestione dei processi InterProcess Communication 4 Il modello a messaggi utilizza due primitive send (destinazione, messaggio) receive (mittente, messaggio) ed una struttura di interconnessione costituita da canali simmetrici (1 a 1) canali asimmetrici (1 a N) o (N a 1) mailbox (N a M)

80 Sistema Operativo Architettura degli elaboratori 1 - A. Memo La gestione dei processi produttore - consumatore 1 l un processo produce dati ed un’altro li legge per elaborarli, entrambi con tempi variabili l si utilizzano tre semafori ed un buffer –int buffer, contenente N slot di dati (liberi) –sem vuoto, contenente il numero di slot vuoti nel buffer, inizializzato ad N –sem pieno, contenente il numero di slot con dati del buffer, inizializzato a 0 –sem mutex, per impedire l’accesso simultaneo al buffer

81 Sistema Operativo Architettura degli elaboratori 1 - A. Memo La gestione dei processi produttore - consumatore 2 void produttore(){ // produrre dato wait(vuoto); wait(mutex); // invia dato // in buffer signal(mutex); signal(pieno); } void consumatore(){ wait(pieno); wait(mutex); // leggi dato // dal buffer signal(mutex); signal(vuoto); // consumare dato }

82 Sistema Operativo Architettura degli elaboratori 1 - A. Memo La gestione dei processi produttore - consumatore 3 si può risolvere anche con il modello a messaggi void produttore(){ int dato, mess do { // produrre dato receive(consID,mess); mess=dato; send(consID,mess); } while (!finito); } void consumatore(){ int dato, mess init_buffer(); do { receive(prodID,mess); dato=mess; // consumare dato send(prodID,NULL); } while (!finito); } NNN

83 Sistema Operativo Architettura degli elaboratori 1 - A. Memo La gestione dei processi stallo 1 l i processi A e B hanno entrambi bisogno delle due risorse R e Q l A chiede l’accesso alla risorsa R e poiché è libera ne ottiene l’utilizzo esclusivo l B chiede l’accesso alla risorsa Q e poiché è libera ne ottiene l’utilizzo esclusivo l A chiede l’accesso alla risorsa Q, ma poiché è occupata si pone in attesa l B chiede l’accesso alla risorsa R, ma poiché è occupata si pone in attesa (altro esempio: incrocio stradale e precedenza)

84 Sistema Operativo Architettura degli elaboratori 1 - A. Memo La gestione dei processi stallo 2 Conzioni di stallo (o deadlock) necessarie e sufficienti: –accesso esclusivo alla risorsa –presenza dello stato di blocco nel SO –non ricorso alla tecnica del pre-rilascio –lista circolare chiusa tra processi e risorse

85 Sistema Operativo Architettura degli elaboratori 1 - A. Memo La gestione dei processi stallo 3 Ci sono almeno tre modi per affrontare lo stallo: l prevenirlo, cercando che almeno una delle condizioni precedenti non si verifichi mai l ripristinarlo, ammettendo che si possa verificare lo stallo ma essere in gardo di riconoscerlo ed avere a disposizione una procedura di recupero l ignorarlo, sapendo che la probabilità di stallo è molto bassa, non prendere alcuna cautela contro di esso; se succede, pazienza.

86 Sistema Operativo Architettura degli elaboratori 1 - A. Memo La gestione dei processi stallo 4 l Prevenzione sulle cause –accesso esclusivo alla risorsa l per alcune risorse non ci sono alternative –stato di blocco l impossibile da eliminare –no pre-emption l per alcune risorse non è possibile –attesa circolare l difficile ed onerosa da valutare

87 Sistema Operativo Architettura degli elaboratori 1 - A. Memo La gestione dei processi stallo 5 l Prevenzione sulla richiesta di accesso –ad ogni richiesta di accesso, verificare se questa porta allo stallo –in caso affermativo però non si sa bene cosa fare –è oneroso valutare la possibilità di stallo ad ogni richiesta –un’altra possibilità è di richiedere all’inizio a tutti i processi quali risorse richiederanno e schedularne l’attività in maniera controllata

88 Sistema Operativo Architettura degli elaboratori 1 - A. Memo La gestione dei processi stallo 6 l Riconoscimento –riconoscere lo stallo è molto oneroso: con una certa frequenza (ogni secondo?) si deve bloccare l’avanzamento del sistema, analizzare lo stato di tutti i processi attivi e verificare se quelli in attesa costituiscono una lista circolare chiusa –il ripristino da uno stato di blocco può essere effettuato solo terminando uno dei processi

89 Sistema Operativo Architettura degli elaboratori 1 - A. Memo La gestione dei processi stallo 7 Il problema dei cinque filosofi affamati Cinque filosofi sono seduti ad un tavolo circolare, e ciascuno ha davanti un piatto di spaghetti ed una forchetta alla sua destra. Per mangiare gli spaghetti hanno bisogno di due forchette. I filosofi alternano momenti di meditazione a momenti di alimentazione.

90 Sistema Operativo Architettura degli elaboratori 1 - A. Memo La gestione dei processi stallo 8 soluzione con stallo void filosofo_i_esimo(){ while (1) { // medita forchetta_on(i); forchetta_on((i++)%5); // mangia forchetta_off(i); forchetta_off((i++)%5); }


Scaricare ppt "Sistema Operativo Architettura degli elaboratori 1 - A. Memo 283 6 Sistema Operativo 6Generalità 6.1Classificazioni e definizioni 6.2Struttura generale."

Presentazioni simili


Annunci Google