CAPITOLO 18 LA PROGRAMMAZIONE CONCORRENTE

Transcript

1 CAPITOLO 18 LA PROGRAMMAZIONE CONCORRENTE Origini della CONCORRENZA Competizione tra processi per ottenere (e condividere) le Risorse: CPU, memoria, canali di I/O, files, ecc... Necessità di comunicazione tra processi CONTESTI DELLA CONCORRENZA Applicazioni multiple: per condividere dinamicamente il tempo di calcolo tra applicazioni; Applicazioni strutturare: gestione della progettazione modulare progettazione strutturata Struttura del sistema operativo. PRINCIPI BASE DELLA CONCORRENZA MUTUA ESCLUSIONE PRODUTTORE CONSUMATORE MONITOR LETTORI - SCRITTORI Le origini della concorrenza vanno ricercate sicuramente nella competizione dei processi per ottenere le risorse e condividerle, quali ad esempio la CPU, la memoria, i canali di I/O, i files e tutte le altre risorse. Inoltre, l origine della concorrenza è legata alla necessità che hanno i processi di comunicare tra di loro. I contesti in cui sorge il problema della concorrenza sono: le applicazioni multiple per condividere dinamicamente il tempo di calcolo tra le diverse applicazioni e, quindi tra i diversi processi; le applicazioni strutturate per la gestione della progettazione modulare e quindi nella programmazione strutturata; infine, essendo il più complesso software quello del sistema operativo stesso, il problema della concorrenza nasce primariamente proprio nella strutturazione del sistema operativo. In questo corso vedremo i principi base della concorrenza guardando: la mutua esclusione, il problema del prodottore e consumatore, i monitors ed analizzeremo il problema classico in sistemi operativi e nella multiprogrammazione concorrente dei lettori-scrittori. Esempio di possibile perdita di coerenza nell'uso della procedura "echo" procedure echo; var out, in: character; begin input (in,tastiera); out:=in; output (out,schermo); end. Cosa succede se in multi-programmazione questa procedura viene condivisa? Si risparmia spazio in memoria ma se due processi concorrenti non completano la procedura correttamente un in si perde ed il successivo appare sullo schermo due volte. In questa slide viene presentato un esempio di perdita di coerenza nell uso in una procedura semplice, elementare di uso comune nei calcolatori: è la procedura echo cioè quella che permette di far vedere a monitor quello che viene digitato da tastiera. Dopo la presa visione del codice ci si chiede cosa succede se in multiprogrammazione questa procedura viene condivisa? Innanzitutto si risparmia spazio di memoria, perché viene memorizzata una sola volta e più processi la utilizzano. Proviamo a guardare i vari passi della procedura e ad immaginare che, dopo che la procedura, che chiamiamo P1 ha eseguito l input da tastiera e il contenuto della locazione in si è portata in out, questa procedura, essendo condivisa, viene sospesa. Il processo P2 che inizia ad utilizzare la procedura, trasferirà l input della tastiera in in, il contenuto di in in out (e quindi il contenuto precedente di out si perde) ed infine il contenuto di out sullo schermo. Quando la procedura P1 viene riavviata, accade che il contenuto ultimo di out torna sullo schermo e il risultato è che il secondo carattere viene visualizzato a monitor due volte e il primo viene perso. 1

2 PROBLEMI DI PROGETTAZIONE DOVUTI ALLA CONCORRENZA E SOLUZIONI Il S.O. deve tenere traccia dei cambiamenti di stato dei processi attivi che vengono registrati nei PCB o nelle Entry della tabelle dei processi e ovviamente sono accodati nelle varie code; Il S.O deve allocare e de-allocare le risorse: tempo di elaborazione; memoria; file; dispositivi di i/o; Il S.O. deve proteggere i dati (sistemi di protezione); Il risultato deve essere indipendente dalla velocità di esecuzione dei processi. Per assicurare ciò occorre studiare l interazione tra processi INTERAZIONE FRA PROCESSI come avviene Il problema di progettazione legato alla concorrenza in un sistema operativo è sostanzialmente quello di tenere traccia del cambiamento dello stato dei processi e questo viene fatto mediante registrazioni nelle strutture dati che, a seconda del sistema operativo, possono essere i Process Control Block (PCB) oppure le Entry della tabella dei processi. Il sistema operativo, ovviamente, deve allocare e deallocare le risorse per ciascun processo, dando un tempo di elaborazione, mettendo a disposizione una quantità di memoria sufficiente, i files che saranno utili al processo e i dispositivi di I/O di cui lo stesso processo dovrà far uso. Il sistema operativo, in questo caso, deve proteggere i dati e i risultati devono essere indipendenti dalla velocità di esecuzione di ciascuno dei processi. Per assicurare le soluzioni a questi problemi occorre studiare l interazione tra i processi. In questa slide è riportata una mappa generale del tipo di interazione tra i diversi processi. Vediamo che nella prima colonna sono riportati i diversi gradi di conoscenza che un processo può avere degli altri processi e notiamo che: i processi possono non vedersi tra di loro, è il caso del contenuto della prima cella; i processi possono vedere gli altri processi indirettamente, ad esempio attraverso oggetti condivisi, come ad esempio delle parti di memoria condivisa; i processi vedono gli altri processi direttamente usando delle primitive di comunicazione. Lungo l asse orizzontale sono riportate: le relazioni che sussistono tra i vari processi; l influenza che un processo ha su gli altri; i possibili problemi di controllo che si presentano. Per esempio: 2

3 Per i processi che non si vedono tra di loro, la relazione tra di essi non può che essere di competizione e le influenze che un processo ha sugli altri sono che i risultati di un processo dipendono dalle informazioni ottenute dagli altri e il tempo di esecuzione dei processi può cambiare. I problemi in questo caso sono di controllo per la mutua esclusione, si può verificare lo stallo e si può verificare lo stavation, nel senso che un processo può rimanere indefinitivamente in attesa. Per i processi che vedono gli altri processi indirettamente la relazione è una cooperazione tramite condivisione e le influenze che un processo ha sugli altri sono che i risultati di un processo possono dipendere dalle informazioni ottenute dagli altri processi e il tempo di esecuzione dei processi può cambiare. In questo caso i problemi che si possono presentare sono la gestione della mutua esclusione, lo stallo, la starvation e la perdita di coerenza dei dati. Da ultimo la relazione che esiste tra processi che vedono gli altri processi direttamente è di cooperazione tramite comunicazione. L influenza che un processo ha sugli altri è che i risultati di un processo possono dipendere dalle informazioni ottenute dagli altri e il tempo di esecuzione dei processi può cambiare. Anche questo terzo caso i problemi che si sono incontrati sono: il possibile stallo e la possibile starvation. COMPETIZIONE I processi che non si vedono tra di loro, in sostanza, sviluppano una competizione per poter usare una risorsa. Per assicurare il controllo dell uso della risorsa, questi processi devono garantire la mutua esclusione, ossia un processo alla volta deve accedere alla risorsa. Consideriamo il caso, ad esempio, di una stampante che deve essere utilizzata da più processi. Per evitare che linee diverse, appartenenti a processi diversi, vengono stampati alternativamente in un unico testo, è necessario che la stampante venga dichiarata come una risorsa critica e che l accesso alla risorsa critica venga effettuato dai processi attraverso una sezione critica, in modo che, una volta che uno di questi ha preso il controllo della risorsa critica, porta a termine il suo lavoro e cede la risorsa ad altri processi che sono in competizione per ottenerla. La mutua esclusione viene gestita con l uso delle sezioni critiche e attraverso apposite comandi che qui sono definiti come entracritica ed escicritica. I problemi che si presentano in questo caso sono: il deadlock, nel senso che qualcuno dei processi si può bloccare la starvation, nel senso che qualche altro processo può rimanere indefinitivamente in attesa. 3

4 Programma di rappresentazione astratta del meccanismo della mutua esclusione In questa slide è riportata la rappresentazione astratta del meccanismo con cui si può garantire la mutua esclusione. Il programma è così rappresentato: ci sono un certo numero di processi in concorrenza tra di loro per ottenere una risorsa critica R. Sono gli n processi chiamati P(1), P(2),, P(n) messi in competizione tra di loro tra i due costrutti parbegin e parend che sono in coda al programma che viene presentato. La i-esima procedura P(i) corrisponde alla parte di codice qui rappresentata, dopo il begin, tra il costrutto repeat- forever. Vediamo che il processo i-esimo P(i) entra nella sezione critica della risorsa R usa la risorsa critica, esce dalla regione critica, rilascia la risorsa critica e poi continua il resto del programma relativo alla procedura i- esima. COOPERAZIONE TRAMITE COMUNICAZIONE La cooperazione tra processi avviene mediante lo scambio di messaggi. Questa parte sarà approfondita nel dettaglio successivamente. Si può dire già da ora che possono presentarsi sia stallo che starvation, ma quando c è comunicazione attraverso l uso di messaggi, non è necessario garantire la mutua esclusione. MECCANISMI PER LA MUTUA ESCLUSIONE I meccanismi per la mutua esclusione devono soddisfare i seguenti requisiti: Un solo processo alla volta deve accedere alla sezione (o risorsa) critica; Ogni processo deve poter accedere dopo un tempo finito di attesa in coda (pertanto ogni processo deve restare nella sezione critica per un tempo finito) ; Nessun processo deve aspettare infinitamente (no stallo o starvation); Non ci devono essere limitazioni sulla velocità di esecuzione. (Dijkstra) E infine ovvio che una volta specificato un meccanismo di accesso, tutti i processi devono accedere alla risorsa tramite quel meccanismo I contenuti di questa slide sono dovuti a Dijkstra. I meccanismi della mutua esclusione devono soddisfare i seguenti requisiti: un solo processo alla volta deve accedere alla sezione o risorsa critica; ogni processo deve poter accedere dopo un tempo finito di attesa in coda, pertanto ogni processo deve restare nella sezione critica per un tempo finito; nessun processo deve aspettare per un tempo infinito; non ci devono essere limitazioni sulla velocità di esecuzione. E infine ovvio che una volta specificato un meccanismo di accesso, tutti i processi devono accedere alla risorsa tramite quel meccanismo. 4

5 MECCANISMI PER LA MUTUA ESCLUSIONE I meccanismi per garantire la mutua esclusione si possono realizzare: con approcci software: nei prossimi learning objects presenteremo gli algoritmi di Dekker e Peterson come esempi di approccio software per garantire la mutua esclusione; usando particolari istruzioni di macchina, ossia delle procedure atomiche che una volta avviate non possono più essere interrotte, implementate in software oppure implementate in firmware e tra queste ci sono le istruzioni test-andset e scambio da ultimo la mutua esclusione, come precedentemente detto, può essere ottenuta usando dei supporti del sistema operativo o dei linguaggi di programmazione, detti messaggi. 5