Parte 2: Gestione dei Processi. 4.1 Concetto di Processo Stato del processo

Transcript

1 Parte 2: Gestione dei Processi 1 Il processo è l unità di lavoro nella maggior parte dei sistemi operativi. È quindi il centro di tutta la teoria dei Sistemi Operativi Il sistema operativo è responsabile della creazione e cancellazione dei processi di sistema e utente, scheduling dei processi, meccanismi di sincronizzazione, comunicazione e gestione dei deadlock Concetto di Processo Processo =:= programma in esecuzione; è attivo Notare: nomi diversi per concetti molto simili processo, task, job sono equivalenti Processo è sezione codice, Program Counter, registri di macchina (inclusa MMU), stack, sezione dati Stato del processo Due o più processi possono condividere (parte di) codice, (parte di) dati Eseguendo un processo cambia stato rispetto al SO Notare: nomi arbitrari, transizioni fra stati cause: SO, altri processi, mondo esterno

2 Stato del processo Stati: New, Running, Waiting, Ready, Terminated Animazione 5 Process Control Block (PCB) Struttura dati del SO che descrive un processo. Contiene: informazioni di stato, Program Counter, registri CPU, CPU scheduling info, memory management info, accounting, I/O, puntatori per accodare I/O Scheduling dei Processi Multiprogrammazione =:= avere sempre un processo running e niente CPU looping massima utilizzazione Time Sharing =:= spostare la CPU fra i processi frequentemente gli utenti possono (è piacevole) interagire con i processi in esecuzione

3 7 4.2 Scheduling dei Processi Commutazione (switch) della CPU è l operazione fondamentale per realizzare ambedue i concetti Per commutare la CPU occorre una commutazione di contesto: puro overhead microsec 8 Context switch Code di scheduling Quando entrano nel sistema job queue In memoria, pronti per eseguire (manca la CPU disponibile) ready queue (RQ) In attesa della fine di una operazione di I/O su un dispositivo device queue

4 10 Code di scheduling Code di scheduling 11 Diagramma di accodamento =:= mostra il transito fra le varie code Scheduler Scheduling =:= scegliere un processo da una coda ed estrarlo Scheduler =:= componente (del SO) che esegue uno scheduling In un batch system: job scheduler a lungo termine, job spooled su disco CPU scheduler a breve termine, per i job caricati in memoria

5 Scheduler In un sistema time sharing: solo CPU scheduler CPU scheduler deve eseguire frequentemente (ogni 100 msec) e quindi molto velocemente Job scheduler controlla il grado di multiprogrammazione 14 Caratterizzazione dei processi I processi possono essere caratterizzati come: Processo I/O bound: maggior parte del tempo spesa facendo (aspettando!) I/O Processo CPU bound: maggior parte del tempo spesa usando la CPU Process mix: miscela di processi I/O e CPU bound, importante per utilizzare al massimo la CPU e i dispositivi di I/O 15 Medium term scheduler Il mix dei job sottoposti cambia nel tempo può essere necessario ridurre il grado di multiprogrammazione swap del processo su disco (e poi swap-in) Medium term scheduling

6 Operazioni sui processi Creazione Syscall apposita padre e figlio albero di processi Risorse: Risorse del figlio passate dal padre, oppure fornite dal SO Padre e figlio possono condividere alcune risorse (ad es. I/O e memoria); argomenti di inizializzazione provengono dal padre Operazioni sui processi Esecuzione Padre e figlio concorrenti oppure padre attende la terminazione del figlio (sharing della CPU!) Spazio indirizzi il figlio è una copia del padre oppure il figlio ha un nuovo programma (spazio di indirizzi) caricato alla creazione Operazioni sui processi Es. Unix: process identifier; fork per figlio identico, ma la fork nel figlio ritorna 0, mentre nel padre ritorna il process identifier del figlio il programma del padre contiene il codice del padre e del figlio la syscall execve sostituisce il programma corrente con un altro e gli passa argomenti padre e figlio possono così andare per la loro strada

7 Operazioni sui processi DEC VMS ha solo una syscall spawn: nuovo processo, nuovo programma Windows/NT ha tutte e due! Terminazione di un Processo NO istruzione di halt! syscall exit (ci pensa il compilatore a inserirla dopo l'ultima istruzione del main Uccisione di un processo: syscall abort o kill, solo dal padre o da un processo dello stesso utente. Terminazione acascata: con tutta la prole Il processo che muore può restituire info al padre; es exit(parm) e wait(&parm) Processi Cooperanti processi indipendenti =:= non possono / non devono influenzare l'esecuzione a vicenda Cooperanti =:= si influenzano l'un l'altro, per condivisione info accelerazione nel calcolo (se ci sono più CPU) modularità (anche con una sola CPU) convenienza; ad es. compila, esegui, stampa Richiedono comunicazione & sincronizzazione

8 Esempio: Produttore- Consumatore con Buffer Limitato 22 shared var n: integer; type item =...; shared var buffer: array [0..n-1] of item; shared var in, out: 0..n-1; Buffer circolare con due puntatori in e out inizializzati a 0 in -> prossima libera; out -> prima piena vuoto -> in=out; pieno -> in+1 mod n = out Solo n-1 elementi nel buffer! Esempio: Produttore- Consumatore con Buffer Limitato 23 Produttore var nextp: item; repeat <produce un nuovo item in nextp> while in+1 mod n = out do no_op; buffer[in] := nextp; in := in+1 mod n; until false; Esempio: Produttore- Consumatore con Buffer Limitato 24 Consumatore var nextc: item; repeat while in = out do no_op; nextc := buffer[out]; out := out+1 mod n; <consuma l'item in nextc> until false; Animazione

9 Threads Inventati per Condividere risorse fra processi, invece che tenerli isolati Ridurre il costo della commutazione di contesto, che è molto pesante perché bisogna salvare e ripristinare un contesto di processo molto complesso Threads => Thread (filo) =:= sono processi parenti i cui contesti sono molto simili Condividono gran parte del contesto la commutazione di contesto fra thread è poco costosa => anche detti Light Weight Process (LWP) [processi leggeri!] Struttura di un sistema con thread Un processo normale (heavyweight) = task + 1 thread [usiamo task per non confondere con processo] Il Thread è il luogo di attività del task Lo switch di contesto fra thread richiede salvataggio e ripristino solo dei registri della macchina (inclusi SP e PC) tutta la memoria e I/O in comune Notare: ogni thread ha un suo stack!

10 28 Esempio di task con molti thread 29 Thread a livello utente Thread a livello utente possono essere realizzati senza aiuto del SO: un task può cambiarsi i registri come vuole nessuna protezione dello stack, però! nessuna protezione della memoria fra thread parenti: stesso spazio di indirizzi i thread si passano la CPU (virtuale) del task si può chiedere al SO di inviare un evento a tempo in modo da forzare il passaggio della CPU virtuale da un thread ad un altro 30 Thread a livello kernel Problemi quando si entra nel kernel perché il SO può togliere la CPU al task => i thread solo a livello utente sono molto limitati => devono essere supportati dal SO stesso => SO organizzato a thread Mach & OS/2: solo SO thread Solaris 2.x: user-level & SO thread

11 31 Differenze tra kernel e user-level La commutazione fra thread user-level non richiede il SO ed è quindi più veloce e un thread bloccato blocca tutto il task La commutazione fra thread di SO richiede il SO, è più lenta, ma un thread bloccato non blocca tutto il task Thread in Solaris 2.x 32 Ha user-level thread, LWP e kernel thread Gli user-level thread si appoggiano su almeno un LWP Quando un LWP entra nel kernel (syscall) diventa SO thread è può essere bloccato I kernel thread servono per il SO stesso Ogni LWP ha un PCB con info di accounting e di memoria per il task I thread sono essenziali per sfruttare i multiprocessori 33 Solaris 2 Threads

12 Inter Process Communication (IPC) Meccanismi per comunicare e sincronizzare le loro azioni Molti preferiscono message-passing, invece che shared-memory, ma la moda dei thread è dovuta anche alla cattiva performance del message-passing send(message)/receive(message) attraverso un communication link (Notare: logico!) IPC Problemi/scelte per i link come si stabiliscono i link quanti fra ogni coppia di processi quale capacità esistenza di buffer quale dimensione di messaggio unidirezionale oppure bidirezionale IPC Problemi/scelte per send/receive diretta/indiretta simmetrica/asimmetrica buffering automatico/esplicito send by copy/by reference messaggi di lunghezza fissa/variabile

13 Naming Aspetto molto importante: come si riferiscono fra loro i processi? diretto: conoscere il nome del processo send (P, message) receive (Q, &message) indiretto: via mailbox che a sua volta occorre conoscere direttamente per nome send (Mbox1, message) receive (Mbox1, &message) Naming Diretto link automatico, uno solo, esattamente fra ogni coppia di processi, in genere bidirezionale fare produttore/consumatore come esercizio simmetrico: se si devono conoscere ambedue asimmetrico: se solo il mittente deve conoscere il destinatario send(dest, message)/receive(&id, &message) Naming Indiretto link fra processi solo se condividono mbox link fra più processi mittenti e più processi riceventi più link fra gli stessi processi (tanti quante sono le mbox) link uni/bi-direzionale syscall per creare, gestire (controllo degli accessi), distruggere le mailbox

14 Buffering Secondo aspetto molto importante: sarebbe bello che un link avesse capacità (buffering) infinita. NO! Si può essere bloccati sulla send! Capacità zero: mittente e ricevente si devono scambiare il messaggio direttamente (di mano in mano!) chi arriva per primo si blocca si chiama anche rendez-vous (ad es. in ADA) Buffering Capacità limitata a n se la coda è piena il mittente viene bloccato in alcuni SO c è un meccanismo di controllo di flusso mediante crediti, che permette al mittente di sapere quanti messaggi può accodare senza essere bloccato Buffering Casi particolari: Mittente mai ritardato ma un solo buffer nel link si perde il "secondo messaggio se il primo non è stato ancora consumato facile implementazione, difficile utilizzo i thread servono anche per questo! Mittente sempre ritardato finché non riceve una risposta send diversa da reply, che non blocca chi risponde modello di cooperazione a Remote Procedure Call (RPC)

15 4.6.4 Condizioni Eccezionali Particolarmente utili nei sistemi distribuiti È un servizio molto utile notificare la condizione eccezionale, altrimenti occorre definire un protocollo applicativo che non può non essere basato su timeout e CRC (Cyclic Redundancy Code) Eventi: terminazione del processo con cui si interagisce messaggi perduti messaggi modificati nella trasmissione (errori o falsificazioni) Un esempio: MACH 44 IPC a scambio di messaggi via port (è una mbox) anche per le syscall: Kernel & Notify Port msg_send, msg_receive, msg_rpc per RPC (send & receive), port_allocate FIFO queue per il sender Header del messaggio con lunghezza, mbox del destinatario, mbox su cui il mittente vuole una risposta; dati tipati per poter spedire oggetti del SO stesso Un esempio: MACH Su mbox piena attesa indefinita oppure al più n msec, oppure ritorno immediato; più cache temporanea di un solo messaggio (con un messaggio del kernel che avverte che la cache è di nuovo disponibile (controllo di flusso!) Mailbox set per attesa non-deterministica: essenziale per programmare applicazioni efficienti, conveniente perché i mittenti non ne devono essere a conoscenza MACH evita di copiare mediante utilizzo della memoria virtuale (vedremo!) 45