Torna alla pagina di Sistemi Operativi
:: Appunti caotici ::
Lezione 1
Thread
Pag 1
Sommario
Ciò che si farà in questa lezione sarà vedere i flussi di esecuzione in modo diverso, in particolare quando questi sono fortemente correlati.
Pag 2
Motivazioni
Tra le attività tipiche di un'applicazione ricordiamo:
- controllo del flusso di operazioni, ovvero svolgere valutazioni di tipo booleano che fungono da controllo sui blocchi di attività da andare ad eseguire
- I/O
- elaborazione, ovvero la manipolazione dei dati nella memoria centrale e nei registri del processore
In applicazioni ad alta disponibilità di servizio e basso tempo di risposta (ad esempio server web), la richiesta di esecuzioni di più flussi di controllo nello stesso processo per attività simili (magari anche da utenti diversi) potrebbe rappresentare - e spesso lo rappresenta - un problema.
Una soluzione semplice potrebbe essere attivare tanti processi che erogano il servizio quante sono le richieste dello stesso. Gli svantaggi sono evidenti:
- è spesso impossibile prevedere a priori il numero di richieste di accesso
- il sistema è lento e con una gestione poco furba delle risorse. Se ad esempio esiste una risorsa a cui accedono praticamente tutti i processi, ognuno di essi dovrà andarsela a caricare nel proprio spazio di memoria, sprecando tempo e spazio, anche se la risorsa è sempre la stessa.
Sarebbe dunque bello se operazioni similari su dati diversi operassero in modo più correlato, magari su un'area di memoria centrale condivisa.
Concetto di thread (1)
Sappiamo già che un processo è un flusso di esecuzione che ha un suo preciso spazio nella memoria centrale. Il thread è invece un gruppo di flussi di controllo autonomo sullo stesso programma che accedono alla stessa porzione di memoria centrale.
I processi possono essere dunque suddivisi in:
- processi tradizionali, con un solo thread, anche detti pesanti
- processi multi-thread, caratterizzati da più flussi di controllo dell'esecuzione di istruzioni in parallelo (i thread, appunto) operanti contemporaneamente e con parte delle informazioni in memoria centrale condivise. In questo modo per un thread sarà possibile reperire il risultato di un'operazione proveniente da flussi diversi della computazione.
Pag 3
Concetto di thread (2)
Pur avendo in comune lo stesso codice, due thread diversi hanno comunque contesti specifici su cui operare (quindi registri e stack separati), in modo da poter eseguire operazioni diverse prese da parte diverse del codice. Se utilizzassero stesso stack e registri ovviamente eseguirebbero le stesse cose nello stesso momento.
La condivisione la porzione di dati del processo garantisce quella proprietà di memoria condivisa presupposta nel concetto stesso di thread. Occorre però una sincronizzazione tra i vari flussi, per evitare che leggano dati inconsistenti (perché ad esempio modificati da altri).
Benefici
- prontezza di risposta (se ho thread liberi servono immediatamente l'utente)
- condivisione (nativa) di risorse
- economia nell'occupazione della memoria centrale (risparmio memoria nella rappresentazione delle informazioni nel sistema)
- utilizzo di architetture multiprocessore, nel qual caso potrei avere un processore dedicato alla gestione di ogni thread in parallelo (ottenendo quindi una condivisione efficiente nativa e diretta delle informazioni)
Pag 4
Supporti di gestione
...
Torna alla pagina di Sistemi Operativi
