Riassunto del libro di Sistemi Operativi - Capitolo 4: i processi

 :: Riassunto capitolo 4: I processi ::

Torna alla pagina di Sistemi Operativi

Processo = unità di lavoro dei sistemi time-sharing.

SO = insieme di processi: quelli di SO, e quelli utente.

4.1 Il concetto di processo

4.1.1 I processi

Livello informale: processo = programma in esecuzione

Processo > codice del programma, perché include

• program counter = attività corrente
• valore dei registri
• stack proprio
• sezione dati
• heap (spazio dinamico, non obbligatorio)

Programma = entità passiva Processo = entità attiva

2 processi possono essere associati al medesimo programma => ma sono sempre 2 diverse istanze di esecuzione dello stesso codice.

4.1.2 Lo stato dei processi

Stato del processo = rispetto all'uso del computer => la modalità del processo in rapporto all'uso del processore e delle risorse.

• nuovo = processo appena creato
• in esecuzione = le istruzioni vengono eseguite
• in attesa = attende qualche eventi, eg I/O, segnali da altri processi, risorse
• ready = ha tutto quello che gli serve, tranne la CPU
• terminato = ha finito la sua esistenza

Ocio: sono termini arbitrari, e molti SO ne hanno di diversi o di più numerosi.

OCIO: nel singolo istante un solo processo è in esecuzione, mentre molti altri sono in attesa o pronti.

4.1.3 Il blocco di controllo del processo

Processo = rappresentato nel SO dal Process Control Block (PCB).

Contiene:

• Stato del processo
• Program Counter
• Registri della CPU
• Info per la schedulazione sulla CPU (eg priorità o altri parametri richiesti)
• Info per la gestione della memoria centrale (registri base e limite, tabelle dei segmenti => a seconda del sistema usato dal SO)
• Info per l'accounting = quantità di CPU e di tempo usati, limiti di tempo
• Informazioni sullo stato dell'I/O = lista dei dispositivi di I/O allocati al processo (file aperti etc.)

4.1.4 I thread

Finora, 1 programma istanziato = 1 processo = 1 flusso di controllo di esecuzione = 1 thread.

Ma nel capitolo 5 vedremo bla bla.

4.2 Schedulazione dei processi

Multiprogrammazione = più processi caricati in memoria per eseguirli "contemporaneamente" => lo schedulatore decide quale mettere in esecuzione.

1 processore = 1 processo in esecuzione nel singolo istante 2+ processori = 1 processo per processore.

4.2.1 Le code di schedulazione

Processo creato => infilato in una coda di lavori = contiene tutti i processi del sistema.

Processo ready => infilato nella Coda dei processi pronti

Ci sono anche altre code, eg una coda per ogni dispositivo I/O.

Quando viene selezionato per l'esecuzione dallo schedulatore, il processo viene dispatched ed è messo in esecuzione sulla CPU.

Quando è in esecuzione, può accadere che:

• il processo chiede I/O => messo nella corrispondente coda I/O
• il processo crea un sottoprocesso e ne attende la terminazione
• il processo viene rimosso forzatamente dalla CPU eg per un interrupt, e quindi rimesso in coda

In pratica passa da una coda all'altra finché non termina.

4.2.2 Gli schedulatori

Selezionare quale processo mettere in CPU = compito dello schedulatore.

Schedulatore a lungo termine = job scheduler = usato nei sistemi a lotti: sceglie tra tutti i processi quelli da eseguire dalla periferica di archiviazione.

Schedulatore a breve termine = CPU scheduler = sceglie tra i processi in memoria centrale, pronti per l'esecuzione, e alloca la CPU ad uno di essi.

Differenze tra i due: Lungo termine = eseguito raramente VS breve termine = eseguito spesso (eg 100 ms)

Processi = in un dato momento possono essere:

• CPU-bound = passa il tempo a computare
• I/O-bound = richiede I/O

=> lo schedulatore a lungo termine deve scegliere un buon compromesso tra processi I/O- e CPU-bound, se no la CPU rimane inutilizzata troppo a lungo o male.

In alcuni sistemi lo schedulatore a lungo termine è assente o minimale => UNIX e Windows: tutti i processi sono gestiti dallo scheduler a breve termine => ci pensa l'utente: se le prestazioni calano troppo perché ci sono troppi processi, l'utente ne accopperà qualcuno.

Schedulatore a medio termine: introdotto in alcuni SO. => a volte è utile ridurre il grado di multiprogrammazione (quanti processi sono attualmente in memoria)

=> swapping è spostare un processo da memoria centrale a memoria di massa (swapped out), o viceversa (swapped in).

Utile ad esempio per bilanciare tra troppi I/O- o CPU-bound.

4.2.3 Il cambio di contesto

Contesto di un processo = stato di esecuzione

=> cambio di contesto = context switch = salvare lo stato di esecuzione di un processo nella PCB e caricare dalla stessa PCB il contesto di un altro processo, ed eseguirlo.

Può essere realizzato in HW o in SW.

È tempo di gestione di sistema: quando si cambia il contesto, il SO non fa niente per l'evoluzione dei processi.

È anche lento => si usano i thread per cercare di velocizzarlo o evitarlo del tutto.

4.3 Operazioni sui processi

Ci sono SO in cui i processi sono creati e distrutti dinamicamente, ed eseguiti in modo concorrente => occorre un meccanismo per creare e terminare i processi.

4.3.1 Creazione dei processi

Un processo chiama il SO per creare un nuovo processo => diventa il padre di un processo figlio => se il figlio a sua volta genera, ho un albero di processi.

Processo = ha bisogno di risorse:

• gliele può dare il SO
• gliene dà alcune, o tutte, il padre

Se gliele dà il padre, il SO "respira" meglio.

Dati di inizializzazione: il padre può passarne quanti ne vuole al figlio, per inizializzarlo come preferisce.

Creazione di figli: 2 possibilità:

1. il padre ed il figlio sono concorrenti
2. il padre aspetta che il figlio (o tutti i figli) termini e poi riprende

Spazio di indirizzamento del processo figlio: 2 possibilità:

1. il figlio è un duplicato del padre => stesso programma, stessi dati
2. il figlio ha un nuovo programma nel suo spazio privato.

Esempio di UNIX:

1. il padre fa una fork
2. il figlio fa una exec e sostituisce i suoi dati con quelli del programma che chiama con la exec

4.3.2 Terminazione dei processi

Terminazione normale: un processo arriva alla sua fine naturale e dice al SO di riprendersi le risorse: chiamata exit.

Terminazione anormale: per errori vari il padre chiama l'abort su di un figlio:

• il figlio sta usando risorse che non dovrebbe
• il figlio non serve più
• il padre sta terminando e il SO non permette che un processo figlio esista se il padre non esiste più = terminazione a cascata

Un'alternativa a quest'ultimo punto è che a un processo orfano viene assegnato come padre il processo init, che è sempre in esecuzione => il figlio sa quindi dove mandare i suoi dati in output.

4.4 Processi cooperanti

• Processo indipendente = non può influenzare o essere influenzato da altri processi in esecuzione.
• Processo cooperante = invece sì.

A che serve la cooperazione:

• Condivisione delle info tra processi
• Velocizzazione della computazione = divido un compito in sottocompiti, e li eseguo in modo parallelo (occorre però HW parallelo)
• Modularità
• Convenienza = un utente può fare cose in parallelo (eg scrivere e stampare)

Esecuzione concorrente => meccanismi per comunicare e sincronizzare i processi.

Esempio di comunicazione con spazio di memoria condiviso: un buffer riempito da un processo, e svuotato da un altro processo => vanno sincronizzati per evitare che il consumatore consumi oggetti non ancora prodotti.

Buffer illimitato = il produttore scrive quanto gli pare; il consumatore legge e si ferma solo se il buffer è vuoto.

Buffer limitato = il produttore scrive e si blocca quando non c'è più spazio nel buffer: il consumatore legge e si ferma se il buffer è vuoto.

Buffer = o viene fornito dal SO, o si programma una zona di memoria condivisa tra processi.

4.5 Comunicazione tra processi

Servono meccanismi di comunicazione tra processi = InterProcess Communication (IPC).

IPC = meccanismi per comunicare e sincronizzarsi senza condividere lo spazio di indirizzamento => miglior modo per ottenere ciò è usare il passaggio di messaggi.

4.5.1 Lo scambio di messaggi

Due operazioni:

• send(messaggio)
• receive(messaggio)

Messaggi: dimensione fissa o variabile.

È necessario un canale di comunicazione tra i due processi => la realizzazione fisica del canale non ci interessa, invece guardiamo alla realizzazione logica.

Metodi per implementare logicamente le send/receive:

• comunicazione diretta VS comunicazione indiretta
• comunicazione sincrona VS comunicazione asincrona
• bufferizzazione automatica VS bufferizzazione esplicita

4.5.2 La denominazione dei processi

I processi che vogliono comunicare devono potersi identificare: in modo diretto o indiretto.

4.5.2.1 La comunicazione diretta

Ogni processo comunicante conosce esplicitamente l'altro.

Quindi, le primitive diventano:

• send(processo, messaggio)
• receive(processo, messaggio)

Il canale che si forma in questo modo ha le seguenti proprietà:

• connessione automatica fra processi, una volta che sanno le rispettive identità
• connessione associata esattamente a 2 processi
• fra ogni coppia di processi esiste esattamente 1 connessione

=> indirizzamento simmetrico = ogni processo usa il nome dell'altro per comunicare.

Variante = indirizzamento asimmetrico = il mittente conosce il destinatario, ma il destinatario non conosce il mittente.

Svantaggi (sia simmetrico che asimmetrico): se cambio l'id di un processo, devo rifare il canale di comunicazione da capo.

4.5.2.2 La comunicazione indiretta

I messaggi sono mandati attraverso mailbox o porte.

Mailbox = struttura in cui oggetti vengono depositato da qualcuno e prelevati da altri. Ogni mailbox ha il suo id.

Le primitive diventano:

• send(mailbox, messaggio)
• receive(mailbox, messaggio)

Proprietà del canale così creato:

• connessione tra due processi solo se hanno una mailbox condivisa
• connessiona associabile a più di 2 processi
• fra ogni coppia di processi può esserci più di una connessione, e ciascuna connessione corrisponde ad una mailbox diversa

Se ci sono più processi che eseguono una receive da una mailbox, chi leggerà?

• posso proibire che più di 2 processi siano associati ad una mailbox
• posso permettere solo ad un processo alla volta di fare la receive
• posso far decidere arbitrariamente al sistema quale dei processi in ascolto (ma non tutti, solo uno) leggerà il messaggio.

Proprietà della mailbox:

• del SO
• di un processo

Mailbox del SO:

• indipendente dai processi
• il SO deve offrire meccanismi per creare, mandare e inviare, distruggere una mailbox

Mailbox del processo:

• un processo ne è il proprietario
• altri sono gli utenti

=> il proprietario è unico => non c'è confusione su chi dovrebbe leggere.

Le proprietà su una mailbox possono cmq essere trasferite ad altri processi.

4.5.3 La sincronizzazione

Comunicazione sincrona = bloccante Comunicazione asincrona = non bloccante

Invio bloccante = il mittente si blocca finché un ricevente non legge.

Invio non bloccante = il mittente invia e torna a lavorare

Ricezione bloccante = il ricevente si blocca finché non arriva un messaggio

Ricezione non bloccante = il ricevente o acquisisce un messaggio, oppure acquisisce null, senza bloccarsi in attesa.

Se sia la send che la receive sono bloccate => c'è un rendezvous tra 2 processi.

4.5.4 La bufferizzazione

• Buffer di capacità 0 = sincronia forzata
• Capacità limitata = sincronia eventuale
• Capacità illimitata = asincronia

4.5.5 Esempio di produttore - consumatore

...

4.5.6 Un esempio: Mach

...

4.5.7 Un esempio: Windows XP

...

4.6 La comunicazione in sistemi client-server

4.6.1 I socket

Socket = il capo estremo di un canale di comunicazione.

Socket = identificato da

• IP
• numero di porta

I server ascoltano su di un certo IP, ad una certa porta.

Client: quando inizia la connessione, il suo SO gli assegna una porta casuale (> 1024) => la comunicazione consiste nella coppia di socket:

• IP e porta del client
• IP e porta del server

TCP = socket orientati alla connessione UDP = socket senza connessione.

4.6.2 La chiamata di procedura remota

...

4.6.3 La chiamata di metodo remoto

...

Torna alla pagina di Sistemi Operativi