|
Appunti informatica |
|
Visite: 967 | Gradito: | [ Picolo appunti ] |
Leggi anche appunti:Elaborato di Intelligenza ArtificialeUniversità degli Studi di Napoli "Federico II" Facoltà La Gestione della MemoriaLa Gestione della Memoria Introduzione Nei sistemi di elaborazione moderni Breve storia dell'archiviazione virtualeBreve storia dell'archiviazione virtuale Con l'avvento dei primi |
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.
Appunti su: |
|