Swappa :: Riassunto del libro di SO: Capitolo 5 - I 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
...

Restore

April 05, 2008, at 02:33 PM by dario -

Added lines 1-114:

(:title Riassunto del libro di SO: Capitolo 5 - I thread:)
%titolo%''':: Riassunto del libro di SO: Capitolo 5 - I thread ::'''

[[Torna alla pagina di Sistemi Operativi -> SistemiOperativi]]

!!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
# Prontezza di risposta: anche se una parte di una appli è bloccata, gli altri thread possono andare avanti
# Condivisione di risorse: stesso spazio di indirizamento, ma più thread che operano
# Economia: meno costoso creare thread che processi; meno costoso il cambio di contesto tra thread
# 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:
# libreria nello spazio utente => user thread
# 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:
# '''asincrona''' = viene ucciso subito
# '''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ì:
# un evento genera un segnale
# il segnale viene consegnato ad un processo
# il processo lo gestisce

Chi gestisce il segnale:
# il gestore di segnali di defaul
# il gestore di segnali definito dall'utente

=> se ho molti thread nel processo, quale di essi gestisce il segnale?
# il thread che l'ha causato <= segnali sincroni
# tutti i thread
# alcuni thread
# 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:
# più veloce che nemmeno creare un thread nuovo ogni volta
# limite massimo al numero di thread in contemporanea

!!!5.3.5 Dati specifici dei thread

[[Torna alla pagina di Sistemi Operativi -> SistemiOperativi]]

Restore