|
Wiki
UniCrema
Materie per semestre
Materie per anno
Materie per laurea
Help
|
|
Uni.SOcap4 History
Show minor edits - Show changes to output
Changed lines 2-3 from:
%titolo%''':: Riassunto del libro di Sistemi Operativi - Capitolo 4: i processi ::''' to:
%titolo%''':: Riassunto capitolo 4: I processi ::'''
Changed lines 273-274 from:
to:
!!!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
...
Added lines 193-274:
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
Changed lines 151-192 from:
to:
* 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
Added lines 4-5:
[[Torna alla pagina di Sistemi Operativi -> SistemiOperativi]] Changed lines 150-152 from:
!!4.4 Processi cooperanti to:
!!4.4 Processi cooperanti
[[Torna alla pagina di Sistemi Operativi -> SistemiOperativi]]
Added lines 113-148:
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à:
# il padre ed il figlio sono concorrenti
# il padre aspetta che il figlio (o tutti i figli) termini e poi riprende
Spazio di indirizzamento del processo figlio: 2 possibilità:
# il figlio è un duplicato del padre => stesso programma, stessi dati
# il figlio ha un nuovo programma nel suo spazio privato.
Esempio di UNIX:
# il padre fa una fork
# 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
Added lines 1-112:
(:title Riassunto del libro di Sistemi Operativi - Capitolo 4: i processi:)
%titolo%''':: Riassunto del libro di Sistemi Operativi - Capitolo 4: i processi ::'''
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
|
|
