Definizione e differenza tra processo e thread nei sistemi operativi e distribuiti

Definizione e differenza tra processo e thread nei sistemi operativi e distribuiti

Processo e Thread

Il processo (in inglese process) dai sistemi operativi è definito come, un programma in esecuzione, e la questione più importante riguardano la gestione e lo scheduling dei processi.
Nei sistemi distribuiti oltre a questi problemi ne sorgono altri riguardanti, ad esempio, l’efficienza di un sistema client-server con tecniche di multithreading.
Un altro aspetto importante è il concetto di virtualizzazione, consente a un’applicazione e al uso ambiente (sistema operativo) di essere eseguita con altre applicazioni, ma in maniera indipendente dal hardware. Consentendo un alta portabilità, e un isolamento da malfunzionamenti o da problemi di sicurezza.

Detto ciò, per eseguire un programma un sistema operativo crea un certo numero di processori virtuali, esso inoltre ha una tabella dei processi, contenente elementi per la memorizzazione dei valori di tali registri.

Un PROCESSO è definito come un processo in esecuzione, ovvero come un programma che al momento attuale è eseguito da uno dei processori virtuali del sistema operativo. È reso trasparente il fatto che più processi possono condividere concorrente mente la stessa CPU e altre risorse hardware. Questa trasparenza è ottenuta a costi abbastanza alti, un esempio è il passare la CPU da un processo al altro.

Il THREAD come il processo esegue il proprio pezzo di codice indipendentemente da altri thread; a differenza dei processi però non viene fatto nessun tentativo di ottenere un alto grado di trasparenza. Quindi un sistema thread gestisce solo l’insieme minimo delle informazioni necessarie alla CPU per essere condivisa da molti thread. Il contesto di un thread è costituito solo dal contesto della CPU, e da altre informazioni per la gestione dei thread.

Definizione e differenza tra processo e thread nei sistemi operativi e distribuiti
Definizione e differenza tra processo e thread nei sistemi operativi e distribuiti

Utilizzo dei thread nei sistemi distribuiti

Vantaggi:

  1. In un sistema a singolo thread quando viene eseguita una chiamata bloccante, viene bloccato l’intero processo, mentre ciò non avverrebbe con un sistema multithread.
  2. Con un sistema multithread è la possibilità di sfruttare il parallelismo quando si esegue un programma su un sistema multiprocessore.
  3. Il multithread è utile anche nel campo delle grandi applicazioni. Esse sono sviluppate come un insieme di programmi cooperanti, ciascuno dei quali deve essere eseguito da un processo separato. (tipico ambienti UNIX).

Contesti del processore e del processo

CONTESTO DEL PROCESSORE VIRTUALE

Un processore virtuale è un processo di sistema, creato dall’OS, in grado di eseguire e riconoscere un determinato set di istruzioni.
Ogni processore virtuale ha lo scopo di gestire ed eseguire un insieme di processi, che compongono un determinato programma.
Il suo contesto si compone di tutti i valori presenti nel processore, che fanno riferimento al processo cui il PV afferisce.

CONTESTO DI PROCESSO (E DI THREAD)

Si tratta di un insieme minimale dei valori presenti nei registri del processore e in memoria.

Implementazione del multithreading (No Sistema Distribuito)

Thread a livello utente (schema n:1)

Questo tipo di approccio prevede la creazione di una libreria eseguita in modalità utente, lasciando il kernel all’oscuro dell’effettiva esistenza dei thread.
Creare e distruggere thread, in questo caso, equivale ad allocare e deallocare spazio in memoria.
Anche l’operazione di cambio di contesto ha un peso a livello computazionale relativamente basso: si tratta di salvare i dati contenuti nei registri della CPU (relativi ad un thread) e di caricarne degli altri (relativi ad un altro thread).

Uno dei problemi principali di questo tipo di modalità è che in caso di chiamata bloccante del thread a livello utente, tutto il processo cui appartiene in thread verrà bloccato, e di conseguenza tutti gli altri thread.
In pratica, applicazioni che richiedono spesso operazioni di I/O non sono adatte a questo tipo di modalità di implementazione.

Thread a livello kernel (schema 1:1)

Insegnando al kernel a conoscere e gestire i thread, i problema delle chiamate bloccanti viene risolto.
Il prezzo da pagare, però, è quello di eseguire una chiamata di sistema ogni qual volta sarà necessaria un’operazione qualsiasi: creazione, distruzione, sincronizzazione.
In questo caso i cambi di contesto vengono affidati al sistema operativo, ed il loro costo è molto più alto che nel caso precedente.

Processi a peso leggero (lwp)

Per ogni normale processo, ci possono essere diversi processi a peso leggero; inoltre il sistema fornisce anche un pacchetto di thread gestiti a livello utente, che quindi comporterà l’estromissione del kernel dalla loro gestione, abbattendo il costo dei context switching a livello dei thread.
Di conseguenza, il pacchetto dei thread potrà essere sfruttato dai processi a peso leggero in maniera tale da riunire i vantaggi di entrambi gli approcci precedenti, limitandone gli svantaggi.

Thread nei sistemi distribuiti

Il vantaggio principale di adoperare i thread nei sistemi distribuiti è che permettono di effettuare chiamate bloccanti, da parte di un thread, senza dover necessariamente bloccare tutto il processo, cui il thread stesso appartiene.

Client multithread

La ricerca della trasparenza nei sistemi distribuiti ha lo scopo principale di nascondere le lunghe latenze di comunicazione (invio dei messaggi e ritorno della risposta ? RTD o round trip delay), dovute in sostanza alla larga distribuzione geografica dei nodi del sistema.
Per fare ciò, è necessario riempire i tempi “morti”, dovuti alla latenza di comunicazione, con altre operazioni, che dovranno essere svolte a prescindere dalla comunicazione stessa.
Ad esempio, nel caso del browser Web, quando un utente vuole accedere (scaricare) una pagina HTML, invece di metterlo in attesa affinché si completi la ricezione di tutta la pagina, si preferisce iniziare a far visualizzare quegli elementi che sono stati già ricevuti.
In tal modo si ottiene un parziale mascheramento della latenza, in questo caso di ricezione, e si permette all’utente di iniziare da subito a leggere ciò che il browser ha già graficamente ricostruito.
Nel frattempo, la ricezione continuerà normalmente, e man mano che i dati arrivano, la pagina viene costantemente aggiornata con gli elementi mancanti (icone, immagini, pulsanti ecc.).
Insomma, l’utilizzo di un thread per ciascuna componente della pagina HTML permette un’elaborazione separata che, però, da sola non produce sostanziali miglioramenti a livello di prestazioni, in quanto se il server è unico, l’invio dei vari componenti sarà sempre serializzato e non parallelo.
Quindi, l’utilizzo di un client multithread deve essere affiancato necessariamente alla presenza di una serie di server replica del server principale, affinché si possano suddividere le richieste sulle varie macchine al fine di bilanciare il carico e parallelizzare le operazioni sulle varie parti della pagina HTML.

Server multithread

La tecnica del multithreading fornisce la maggior parte dei vantaggi sul lato server, in quanto oltre a semplificare notevolmente l’implementazione, rende possibile l’ottimizzazione delle chiamate bloccanti.
Prendiamo in esame un file server, il quale talvolta ha la necessità di accedere a disco, quindi bloccarsi.

Una possibilità è quella di utilizzare un’organizzazione DISPATCHER\WORKER:

  1. un thread dispatcher legge una richiesta inviata dal client, la esamina e la invia al primo thread worker che risulta inattivo
  2. il thread worker che ha ricevuto la richiesta, in caso consista in un accesso a disco, si blocca in attesa che i dati vengano prelevati;
  3. quando un thread worker è in attesa, l’esecuzione passa ad un altro thread inattivo, che può essere sia il dispatcher, sia un altro thread che prima era in attesa ed ora ha completato l’accesso a disco.

Un’altra possibilità è quella di implementare una macchina a singolo thread come una macchina a stati finiti (SINGLE THREAD FINITE STATE MACHINE): in questo caso l’unico thread preleva la richiesta, se si tratta di un dato presente i cache, lo preleva e prepara il messaggio di risposta, altrimenti, in caso di accesso a disco, inserisce tutto ciò che riguarda l’operazione (quali dati prelevare, in che posizione si trovano ecc.) in una tabella, ed il thread prosegue la sua esecuzione senza bloccarsi.

L’esecuzione prosegue analizzando se nella tabella sono presenti operazioni di accesso a disco terminate, in tal caso il thread raccoglie i dati e li invia tramite messaggio di risposta; in caso contrario, il thread preleva una nuova richiesta.

Lo svantaggio di questo tipo di organizzazione è che le chiamate di sistema relativamente all’accesso a disco devono essere necessariamente non bloccanti.

Pubblicato da Vito Lavecchia

Lavecchia Vito Ingegnere Informatico (Politecnico di Bari) Email: [email protected] Sito Web: https://vitolavecchia.altervista.org

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *