:: Riassunto capitolo 5 - I thread ::
Torna alla pagina di Sistemi Operativi
Thread = unità base dell'utilizzo della CPU. Comprende:
Condivide codice, dati e altre risorse con gli altri thread appartenenti allo stesso processo.
Processo tradizionale = 1 thread.
User thread = il kernel non ne sa niente
Kernel thread = gestiti dal kernel
=> paragrafo 5.2
2 vie:
Tra user thread e kernel thread deve esistere una relazione: i modelli multithread ci dicono quale
Molti user thread mappati in un kernel thread
Problemi:
1 user thread = 1 kernel thread
Pro: maggior concorrenza Contro: overhead nella creazione => molti SO limitano il numero max di kernel thread
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.
Se un thread fa una fork, duplica se stesso o l'intero processo?
=> 2 versioni di fork, una per ogni scopo.
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:
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.
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ì:
Chi gestisce il segnale:
=> se ho molti thread nel processo, quale di essi gestisce il segnale?
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.
Esempio: server web che usa un thread per servire le richieste. Problemi:
=> 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:
I thread di un processo condividono i dati del processo => ma hanno anche bisogno di dati propri.
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.
...
...
...
...