PARTE 2 PROCESSI E THREAD

PROCESSI E THREAD

PROCESSO CONCETTO DI PROCESSO = Il processo un programma in esecuzione. l'unit di esecuzione all'interno del SO solitamente esegue in modo sequenziale ( istruzioni vengono eseguite in sequenza , secondo l'ordine specificato nel testo del programma ) SO multiprogrammato consente l'esecuzione CONCORRENTE di pi processi

*NB. d'ora in avanti facciamo riferimento solamente a SO multiprogrammati

il processo rappresentato da : codice ( text ) del programma eseguito dati : variabili globali program counter alcuni registri della CPU stack : parametri , variabili locali a funzioni / procedure inoltre a un processo possono essere associate delle risorse di SO ad esempio : file aperti , connessioni di rete, altri dispositivi di I/O in uso, ecc.. si ha quindi : PROCESSO = { PC, REGISTRI , STACK , TEXT , DATI , RISORSE }

STATI DI UN PROCESSO un processo durante la sua esecuzione pu trovarsi in diversi stati : INIT : uno stato transitorio durante il quale il processo viene caricato in memoria centrale e il SO inizializza i dati che lo rappresentano READY : il processo pronto per acquisire la CPU RUNNING : il processo sta utilizzando la CPU WAITING : il processo sospeso e sta attendendo un evento TERMINATED : un altro stato transitorio relativo alla fase di terminazione e deallocazione del processo della memoria

In un sistema monoprocessore e multiprogrammato uno solo processo si trova ( al massimo ) nello stato di running mentre pi processi possono trovarsi nello stato di ready e waiting

RAPPRESENTAZIONE DEI PROCESSI NEI SO nei SO ad ogni processo viene associata una struttura dati ( descrittore ) : Process Control Block (PCB) che contiene tutte le informazioni relative al processo : - stato del processo - contenuto dei registri di CPU - informazioni di scheduling - informazioni per gestore della memoria - informazioni relative all I/O - informazioni di accounting

PCB PROCESS CONTROL BLOCK ?

SCHEDULING DEI PROCESSI l'attivit mediante la quale la SO effettua delle scelte tra i processi , riguardo a : caricamento in memoria centrale, assegnazione della CPU. In generale il SO compie tre diverse attivit di scheduling : 1scheduling a breve termine ( o di CPU ) 2scheduling a medio termine ( o swapping ) 3scheduling a lungo termine

1.SCHEDULING A BREVE TERMINE quella parte del SO che si occupa della selezione dei processi a cui assegnare la CPU nei sistemi time sharing ad ogni quanto di tempo il SO : decide a quale processo assegnare la CPU effettua il cambio di contesto ( context switch ) ** vedi dopo inoltre lo scheduler a breve termine gestisce la coda dei processi pronti che contiene i PCB dei processi che si trovano nello stato di Ready.

2.SCHEDULING A MEDIO TERMINE detto anche swapper , un trasferimento temporaneo in memoria secondaria di processi ( o di parti di processi) , in modo da consentire il caricamento di altri processi

3.SCHEDULING A LUNGO TERMINE

 quella componente dei SO che seleziona i programmi da eseguire dalla memoria secondaria per caricarli in memoria centrale ( creando i corrispondenti processi ). in particolare : controlla il grado di multiprogrammazione una componente importante dei sistemi batch multiprogrammati non presente nei sistemi time sharing

CAMBIO DI CONTESTO la fase in cui l'uso della CPU viene commutato da un processo ad un altro. Ogni volta che avviene un cambio di contesto tra un processo A e un processo B ( cio A cede l'uso della CPU a B ) si ha : salvataggio dello stato di A ripristino dello stato di B

SCHEDULING E CAMBIO DI CONTESTO le operazioni di scheduling determinano un costo computazionale aggiuntivo che dipende essenzialmente dalla frequenza di cambio contesto, dalla dimensione del PCB e dal costo dei trasferimenti da / verso la memoria

OPERAZIONE SUI PROCESSI

ogni SO multiprogrammato prevede dei meccanismi per la gestione dei processi . I meccanismi necessari sono : creazione , terminazione , interazione tra processi. Esse sono operazioni privilegiate che vengono quindi eseguite in modo kernel

CREAZIONE DI PROCESSI un processo ( padre ) pu richiedere la creazione di un nuovo processo ( figlio )

possibile quindi creare gerarchie di processi Es. Unix

CARATTERISTICHE RELAZIONE PADRE-FIGLIO: CONCORRENZA : padre e figlio procedono in parallelo ( ex. Unix )oppure il padre si sospende in attesa della terminazione del figlio CONDIVISIONE DI RISORSE : le risorse del padre sono condivise con i figli ( es. Unix ) oppure il figlio utilizza risorse soltanto se esplicitamente richieste da se stesso

SPAZIO DEGLI INDIRIZZI : lo spazio degli indirizzi del figlio pu essere una copia di quello del padre ( es. fork() in Unix ) oppure padre e figlio hanno spazi di indirizzi con codice e dati diversi ( es. VMS , stesso processo dopo exec() in Unix )

TERMINAZIONE ogni processo figlio di un altro processo e pu essere a sua volte padre di altri processi . Il SO deve mantenere le informazioni relative alle relazioni di parentela ( nel descrittore infatti viene messo un riferimento al padre ) se un processo termina : il padre pu rilevare lo stato di terminazione tutti i figli terminano

PROCESSI LEGGERI ( THREAD )

un thread ( o processo leggero ) un unit di esecuzione che condivide codice e dati con altri thread ad esso associati. Un insieme di thread che riferiscono lo stesso codice e gli stessi dati detto TASK , intuiamo quindi che codice e dati non sono caratteristiche del singolo thread ma del task al quale esso appartiene. Quindi abbiamo che : THREAD = { PC, REGISTRI , STACK , } TASK = { THREAD1, THREAD2, ., THREADN, TEXT, DATI }

NB. un processo pesante equivale a un task con un solo thread

PROCESSI SINGLE O MULTI THREADED

VANTAGGI DEI THREAD CONDIVISIONE DI MEMORIA : a differenza dei processi ( pesanti ), un thread pu condividere variabili con altri ( appartenti allo stesso task ) MINOR COSTO DI CONTEXT SWITCH : il PCB di thread non contiene alcuna informazione relativa a codice e dati quindi abbiamo una dimensione di PCB minore e di conseguenza un minor costo di context switch MINOR PROTEZIONE : thread appertenenti allo stesso task possono modificare dati gestiti da altri thread

REALIZZAZIONE DEI THREAD alcuni SO offrono anche l'implementazione del concetto di thread ( es. MSWinXP, Linux , Solaris ) REALIZZAZIONE : A LIVELLO KERNEL (MSWinXP, Linux, Solaris, MacOSX) : il SO gestisce direttamente i cambi di contesto tra thread dello stesso task e tra task e fornisce strumenti per la sincronizzazione nell'accesso di thread a variabili comuni A LIVELLO UTENTE ( es. Andrew - Carnegie Mellon, POSIX pthread, vecchie versioni MSWin, Java thread): il passaggio da un thread al successivo ( nello stesso task ) non richiede interruzioni al SO . Il SO vede processi pesanti . SOLUZIONI MISTE : i thread vengono realizzati a entrambi i livelli

SOLUZIONI ADOTTATE : MS-DOS: un solo processo utente ed un solo thread. UNIX: pi processi utente ciascuno con un solo thread.Supporto run time di Java: un solo processo, pi thread. Linux, Windows NT, Solaris: pi processi utente ciascuno con pi thread.

INTERAZIONE TRA PROCESSI i processi , pesanti o leggeri , possono interagire. Possiamo dividire i processi in due categorie : INDIPENDENTI : due processi P1 e P2 sono indipendenti se l'esecuzione di P1 non influenzata da P2 e viceversa INTERAGENTI : P1 e P2 sono interagenti se l'esecuzione di P1 influenzata dall'esecuzione di P2 e/o viceversa

PROCESSI INTERAGENTI Ci sono diversi tipi di interazione tra processi : COOPERAZIONE : interazione prevedibile e desiderata . I processi collaborano per il raggiungimento di un fine comune COMPETIZIONE : interazione prevedibile ma non desiderata . Pu avvenire tra processi che interagiscono per sincronizzarsi nell'accesso a risorse comuni INTERFERENZA : interazione non prevedibile e non desiderata. parzialmente deleteria tra processi.

Ci sono due supporti all'interazione : MEMORIA CONDIVISA : il SO consente ai processi di condividere variabili globali e quindi l'interazione avviene tramite l'accesso a variabili condivise. SCAMBIO DI MESSAGGI : i processi non condividono variabili e interagiscono mediante meccanismi di trasmissione / ricezione di messaggi . Il SO prevede dei meccanismi a supporto dello scambio di messaggi.

ESEMPIO COMPETIZIONE : mutua esclusione Due thread P1 e P2 hanno accesso ad una struttura condivisa organizzata a pila rispettivamente per inserire e prelevare dati. La struttura dati rappresentata da un vettore stack i cui elementi costituiscono i singoli dati e da una variabile top che indica la posizione dellultimo elemento contenuto nella pila. I thread utilizzano le operazioni Inserimento e Prelievo per depositare e prelevare i dati dalla pila. typedef ... item; item stack[N]; int top=-1; void Inserimento(item y) { top++; stack[top]=y; } item Prelievo() { item x; x= stack[top]; top--; return x; } OSSERVAZIONI : Lesecuzione contemporanea di queste operazioni da parte dei processi pu portare ad un uso scorretto della risorsa. Consideriamo questa sequenza di esecuzione: T0 T1 T2 T3 : : : : top++; (P1) x=stack[top]; (P2) top--; (P2) stack[top]=y; (P1)

Viene assegnato a x un valore non definito e lultimo valore valido contenuto nella pila viene cancellato dal nuovo valore di y. Potremmo individuare situazioni analoghe, nel caso di esecuzione contemporanea di una qualunque

delle due operazioni da parte dei due processi. Il problema sarebbe risolto se le due operazioni di Inserimento e Prelievo fossero eseguite sempre in mutua esclusione ( istruzioni indivisibili ). ISTRUZIONI INDIVISIBILI data un istruzione I(d) , che opera su un dato d , essa indivisibile ( o atomica ) se , durante la sua esecuzione da parte di un processo P, il dato d non accessibile ad altri processi che non siano P. I(d) a partire da un valore iniziale d0 pu operare delle trasformazioni fino raggiungere lo stato finale dF. Poich l'istruzione I(d) indivisibile gli stati intermedi non verranno rilevati dagli altri processi concorrenti.

PROCESSI COOPERANTI

Esempio : produttore & consumatore due processi accedono a un buffer condiviso di dimensione limitata: un processo svolge il ruolo di produttore di informazioni che verranno prelevate dall'altro processo ( consumatore ) il buffer rappresenta il deposito di informazioni condiviso

se i processi sono cooperanti necessario sincronizzare i processi :

quando il buffer vuoto ( il consumatore non pu prelevare messaggi ) quando il buffer pieno ( il produttore non pu depositare messaggi )

ES. CODICE PRODUTTORE CONSUMATORE produttore : shared msg Buff [DIM]; main() { msg M; do{ produco(&M); inserisco(M, Buff); } while(!fine); } consumatore : shared msg Buff [DIM]; main() { msg M; do{ prelievo(&M, Buff); consumo(M); } while(!fine);

cosi non va bene . necessario sincronizzare i processi poich cosi abbiamo problemi se il buffer vuoto / pieno. Soluzione : aggiungiamo due variabili logiche condivise : buff_vuoto: se uguale a true, indica che il buffer non contiene messaggi (viene settata dalla funzione di prelievo quando lunico messaggio presente nel buffer viene estratto) buff_pieno: se uguale a true, indica che il buffer non pu accogliere nuovi messaggi, perch pieno(viene settata dalla funzione di inserimento quando lultima locazione libera del buffer viene riempita)