Thread e Multithreading
Se il SO è Multithreaded,
il nuovo processo figlio generato non è considerato propriamente come tale
(proprio codice, proprio PCB) bensì padre e figlio vengono gestiti dal SO come
due distinti Thread di uno stesso processo, cioè il processo padre.
Thread è abbreviazione di thread of execution, cioè filo
dell'esecuzione (si
rifà visivamente al concetto di fune composta da vari fili attorcigliati: se la
fune è il processo in esecuzione, allora i singoli fili che la compongono sono
i thread) e va inteso come una parte del
processo che viene eseguita in maniera concorrente ed indipendente
internamente al processo stesso: un processo ha sempre almeno un thread (sè
stesso) ma può avere più thread eseguiti in parallelo.
A livello di definizioni,
un processo si può definire come l'entità del SO cui sono assegnate
tutte le risorse di sistema per l'esecuzione di una applicazione tranne la CPU,
il thread è invece l'entità del SO o dell'applicazione cui è
assegnata la CPU per l'esecuzione, uno stato di esecuzione (Ready,
Waiting, Running), un contesto (registri della CPU
compreso PC) e uno stack. In termini di differenze, i
processi, solitamente indipendenti tra loro, utilizzano aree di memoria diverse
ed interagiscono solo mediante appositi meccanismi di comunicazione messi a
disposizione dal SO, al contrario i thread di uno stesso processo condividono
con esso le informazioni di stato, la memoria e le risorse allocate al processo;
una differenza fondamentale è inoltre nel meccanismo di attivazione: la
creazione di un nuovo processo è sempre onerosa per il sistema (devono essere
allocate le risorse necessarie alla sua esecuzione) mentre il thread nasce come
parte di un processo già esistente e quindi la sua attivazione avviene in tempi
ridottissimi; infine ciascun thread è identificato da un TID (Thread
Identifier o Thread Handle, omologo del
PID)
e ad esso è associato un Descrittore di Thread (contenente
appunto lo stato d'esecuzione, il contesto e lo stack),
mentre se il SO non gestisce i thread tali informazioni fanno parte dello stato
del processo e sono indicate nel PCB.
I vantaggi del Multithreading sono
dunque evidenti, in quanto si riducono gli overhead del SO legati alla creazione/terminazione
dei processi, alla loro comunicazione e al cambio di contesto. Comunque, quando
non prevista a livello Kernel tramite SVC, la gestione dei thread
può avvenire a livello utente tramite apposite routine di libreria: nel
primo caso esiste certamente un overhead a carico del SO compensato però
dalla possibilità di processare simultaneamente più thread e di schedulare un
altro thread di uno stesso processo laddove un thread sia bloccato; nel secondo
caso non c'è alcun overhead esplicito a carico del SO, la schedulazione
può avvenire secondo esigenze specifiche dell'applicazione (e non in base a
criteri generali stabiliti dal SO) ed è per questo portabile, tuttavia
il parallelismo solo simulato tramite libreria impedisce di sfruttare il
multiprocessing così come l'esecuzione di tutti i thread è soggetta a blocco in
caso di SVC.
[ Picolo appunti ]
