cerca
Riassunto del libro di SO: Capitolo 5 - I thread
modifica cronologia stampa login logout

Wiki

UniCrema


Materie per semestre

Materie per anno

Materie per laurea


Help

Riassunto del libro di SO: Capitolo 5 - I thread

 :: Riassunto capitolo 5 - I thread ::

Torna alla pagina di Sistemi Operativi

5.1 Generalità

Thread = unità base dell'utilizzo della CPU. Comprende:

  • id
  • program counter
  • set di registri
  • stack

Condivide codice, dati e altre risorse con gli altri thread appartenenti allo stesso processo.

Processo tradizionale = 1 thread.

5.1.1 Motivazioni

  • Creare processi è costoso (tempo e risorse, + cambio di contesto)
  • Insensato creare più processi per fare la stessa cosa (eg un server web con più processi)

5.1.2 Benefici

  1. Prontezza di risposta: anche se una parte di una appli è bloccata, gli altri thread possono andare avanti
  2. Condivisione di risorse: stesso spazio di indirizamento, ma più thread che operano
  3. Economia: meno costoso creare thread che processi; meno costoso il cambio di contesto tra thread
  4. Utilizzo di architetture multiprocessore: un thread per processore => esecuzione parallela

5.1.3 Thread nello spazio utente e nello spazio kernel

User thread = il kernel non ne sa niente
Kernel thread = gestiti dal kernel
=> paragrafo 5.2

5.1.4 Le librerie di thread

2 vie:

  1. libreria nello spazio utente => user thread
  2. libreria a livello kernel => kernel thread

5.2 Modelli multithread

Tra user thread e kernel thread deve esistere una relazione: i modelli multithread ci dicono quale

5.2.1 Il modello molti a uno

Molti user thread mappati in un kernel thread

Problemi:

  • se un thread si blocca (eg chiamata I/O), blocca anche tutti gli altri
  • un kernel thread = gira in 1 processore => non sfrutta i sistemi multiprocessore

5.2.2 Il modello uno a uno

1 user thread = 1 kernel thread

Pro: maggior concorrenza Contro: overhead nella creazione => molti SO limitano il numero max di kernel thread

5.2.3 Il modello molti a molti

Molti user thread = un po' di kernel thread (stesso numero, o meno)

Prende i vantaggi e non gli svantaggi dei precedenti 2 modelli

Variante. il modello a 2 livelli = posso usare il molti a molti, o mappare direttamente un user thread in un kernel thread.

5.3 Problematiche relative ai thread

5.3.1 Le chiamate fork() ed exec()

Se un thread fa una fork, duplica se stesso o l'intero processo?

=> 2 versioni di fork, una per ogni scopo.

5.3.2 Cancellazione

Cancellare un thread = terminarlo prima che lui finisca normalmente.

Thread target = il thread che sta per essere cancellato. La cancellazione può avvenire in 2 modi:

  1. asincrona = viene ucciso subito
  2. differita = il target controlla periodicamente se va terminato, e ha la possibilità di morire graziosamente

Problema: cancello un thread che sta usando risorse condivise => inconsistenza dei dati (specialmente con cancellazione asincrona) => meglio la cancellazione differita => esistono i punti di cancellazione dove un thread può morire in modo sicuro.

5.3.3 La gestione dei segnali

Segnali sincroni = consegnati allo stesso processo che ha eseguito l'operazione che ha causato il segnale.

Segnali asincroni = generati da eventi esterni al processo.

Ma tutti funzionano così:

  1. un evento genera un segnale
  2. il segnale viene consegnato ad un processo
  3. il processo lo gestisce

Chi gestisce il segnale:

  1. il gestore di segnali di defaul
  2. il gestore di segnali definito dall'utente

=> se ho molti thread nel processo, quale di essi gestisce il segnale?

  1. il thread che l'ha causato <= segnali sincroni
  2. tutti i thread
  3. alcuni thread
  4. un thread che fa gestione dei segnali

Il problema c'è con gli asincroni: alcuni vanno dati a tutti i thread, altri no. Cmq un segnale non può essere ripetuto, e va gestito 1 sola volta => viene dato al primo thread che non lo rifiuta, di solito.

In certe versioni di multithread si può specificare quali segnali un thread riceve e quali invece no.

5.3.4 Gruppi di thread

Esempio: server web che usa un thread per servire le richieste. Problemi:

  • quanto tempo ci metto a creare un nuovo thread = quanto tempo attende il mio client?
  • così facendo non ho limiti al numero di thread che creo

=> pool di thread (pool = gruppo) = ne creo un po' in partenza, e do la richiesta al primo libero. Se non ce n'è nessuno, la richiesta attende.

Vantaggi:

  1. più veloce che nemmeno creare un thread nuovo ogni volta
  2. limite massimo al numero di thread in contemporanea

5.3.5 Dati specifici dei thread

I thread di un processo condividono i dati del processo => ma hanno anche bisogno di dati propri.

5.3.6 Attivazione dello schedulatore

Modello molti a molti e a 2 livelli = comunicazione tra kernel e libreria dei thread => molti SO che hanno sti sistemi usano il lightweight process = LWP

LWP = struttura dati intermedia tra processo e thread.
L'LWP appare alla libreria dei thread come un processore virtuale su cui schedulare il thread utente.
Se si blocca il kernel thread, si blocca anche l'LWP e infine l'user thread => necessario un LWP per ogni chiamata bloccante.
Un appli decide quanti LWP avere.

Attivazione dello schedulatore = schema di comunicazione tra kernel e libreria dei thread.
Il kernel fornisce a un'appli un certo numero di processori virtuali => l'appli schedula per conto suo i suoi thread sui processori virtuali disponibili..

Upcall = il kernel deve informare l'applicazione di certi eventi => la libreria di thread ha un gestore di upcall.
Eg: un thread sta per bloccarsi => il kernel informa la libreria => essa rischedula i suoi thread.
Il thread bloccato si sblocca => altra upcall => altra rischedulazione.

5.4 Pthread

...

5.5 I thread di Windows XP

...

5.6 I thread di Linux

...

5.7 I thread di Java

...

Torna alla pagina di Sistemi Operativi