Caratteristiche e Differenza tra processo e thread in informatica

Processi VS Thread

Il concetto di processo in informatica è associato ma comunque distinto da quello di thread (abbreviazione di thread of execution, filo dell’esecuzione) con cui si intende invece l’unità granulare in cui un processo può essere suddiviso (sottoprocesso) e che può essere eseguito a divisione di tempo o in parallelo ad altri thread da parte del processore.

In altre parole, un thread è una parte del processo che viene eseguita in maniera concorrente ed indipendente internamente allo stato generale del processo stesso. Il termine inglese rende bene l’idea, in quanto 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.

Un processo ha sempre almeno un thread (se stesso), ma in alcuni casi un processo può avere più thread che vengono eseguiti in parallelo.
Una differenza sostanziale fra thread e processi consiste nel modo con cui essi condividono le risorse: mentre i processi sono di solito fra loro indipendenti, utilizzando diverse aree di memoria ed interagendo soltanto mediante appositi meccanismi di comunicazione messi a disposizione dal sistema, al contrario i thread di un processo tipicamente condividono le medesime informazioni di stato, la memoria ed altre risorse di sistema.

L’altra differenza sostanziale è insita nel meccanismo di attivazione: la creazione di un nuovo processo è sempre onerosa per il sistema (context switching), in quanto devono essere allocate ovvero assegnate risorse necessarie alla sua esecuzione (allocazione di memoria RAM, riferimenti alle periferiche, e così via, operazioni tipicamente onerose); il thread invece è parte di un processo e quindi una sua nuova attivazione viene effettuata in tempi ridottissimi a costi minimi.
In un sistema che non supporta i thread, se si vuole eseguire contemporaneamente più volte lo stesso programma, è necessario creare più processi basati sullo stesso programma. Tale tecnica funziona, ma è dispendiosa di risorse, sia perché ogni processo deve allocare le proprie risorse, sia perché per comunicare tra i vari processi è necessario eseguire delle relativamente lente chiamate di sistema, sia perché la commutazione di contesto tra thread dello stesso processo è più veloce che tra thread di processi distinti.

Avendo più thread nello stesso processo, si può ottenere lo stesso risultato allocando una sola volta le risorse necessarie, e scambiando i dati tra i thread tramite la memoria del processo, che è accessibile a tutti i suoi thread.

Un esempio di applicazione che può far uso di più thread è un browser Web, che usa un thread distinto per scaricare ogni immagine in una pagina Web che contiene più immagini.
Un altro esempio è costituito dai processi server, spesso chiamati servizi o daemon, che possono rispondere contemporaneamente alle richieste provenienti da più utenti.

In un sistema multiprocessore (SMP), si possono avere miglioramenti prestazionali, grazie al parallelismo fisico dei thread. Tuttavia, l’applicazione deve essere progettata in modo tale che essa suddivida tra i thread il carico di elaborazione. Tale progettazione è difficile e soggetta a errori, e il programma risultante, se eseguito su un sistema monoprocessore, potrebbe essere più lento di uno con un solo thread; pertanto oggi sono ancora pochi i software che usano i thread per sfruttare i sistemi SMP.

Bisogna notare inoltre che la mancanza di supporto ai thread da parte del sistema operativo non impedisce la programmazione parallela.
Infatti il parallelismo tra thread può essere simulato da librerie di programmazione o anche dal supporto run-time del linguaggio di programmazione. In tal senso si parla di “thread del kernel” per indicare un thread gestito dal sistema operativo, e di “thread utente” per indicare un thread gestito da una libreria applicativa. Per esempio, alcune versioni di Unix non supportano i thread, per cui si ricorre ai thread utente, altri (per esempio Linux) supportano direttamente i thread a livello del kernel.

Strutture dati relative a processi e thread

Nel sistema operativo, ciascun processo è identificato da un numero, detto PID (Process IDentifier) oppure “process handle”.

Ad un processo sono associate le seguenti strutture dati:

• Uno o più segmenti di codice.
• Uno o più segmenti di memoria dati.
• I descrittori di eventuali risorse in uso (file, finestre, periferiche, ecc.)
• Uno o più thread.

L’insieme di tali informazioni è raccolto o indicizzato da una struttura, unica per ogni processo, detta process control block (abbreviata in PCB). A loro volta, tutti i PCB sono elencati in una struttura detta process table.
Se il sistema operativo gestisce i thread, anche ciascun thread è identificato da un numero, detto TID (Thread IDentifier) oppure “thread handle”.

Ad un thread sono associate le seguenti strutture dati:

• Lo stack delle chiamate di funzione.
• I registri del processore, tra cui il program counter.

Se il sistema operativo non gestisce i thread, le suddette informazioni fanno parte dello stato del processo.

In un sistema operativo multitasking, ci sono più processi contemporaneamente in esecuzione. Di questi, al massimo un numero pari al numero di processori può avere effettivamente il controllo di un processore in un dato istante. I diversi processi possono quindi utilizzare il processore per un periodo limitato di tempo cioè a divisione di tempo, per questo motivo i processi vengono interrotti, messi in pausa e richiamati secondo i noti algoritmi di schedulazione, dando l’impressione all’utente di un processamento parallelo di questi.

Gli stati in cui un processo si può trovare sono:

1. esecuzione (running): il processo ha il controllo di un processore;
2. pronto (ready): il processo è pronto ad essere eseguito, ed è in attesa che lo scheduler lo metta in esecuzione;
3. in attesa o sospeso o bloccato (suspended o blocked): il processo ha eseguito una chiamata di sistema ed è fermo in attesa del risultato;

Con commutazione di contesto (Context switch) si indica infine il meccanismo tramite il quale un processo in esecuzione viene fermato (perché ha eseguito una chiamata di sistema o perché lo scheduler ha deciso di eseguire un altro processo), e un altro pronto viene messo in esecuzione.

Genesi di processi e thread

Al bootstrap del sistema operativo ci sono in esecuzione uno o più processi creati dal sistema operativo stesso. Durante l’avvio del sistema, in base alla configurazione, possono essere creati numerosi processi. Durante la normale operatività, in base alle richieste degli utenti, possono essere creati nuovi processi e altri possono terminare.
Quando il sistema operativo inizia l’esecuzione di un programma, crea un processo dotato di un solo thread. Durante l’esecuzione di tale thread, detto thread principale, il codice può creare altri thread o altri processi con apposite chiamate di sistema.

La creazione di un processo differisce tra i vari sistemi operativi.

In ambiente Windows, si usa la chiamata di sistema “CreateProcess”, con cui si specifica il nome del file contenente il programma eseguibile; tale file viene caricato in memoria ed eseguito.

In ambiente Unix, si usa la chiamata di sistema “fork” per creare un nuovo processo figlio identico al chiamante (processo padre) eccetto che per il valore reso dalla chiamata stessa; e si usa poi la chiamata “exec” in uno dei due per caricare il codice eseguibile di un nuovo programma nel processo corrente, e mandarlo in esecuzione. La creazione di un thread invece, è più uniforme.
Infatti, sia la chiamata di sistema “CreateThread” di Windows che la chiamata di sistema “thr_create” di Solaris (una variante di Unix) richiedono il passaggio dell’indirizzo di una routine, e della dimensione del nuovo stack, oltre ad altri parametri. La chiamata di sistema fa sì che venga eseguito il corpo della routine specificata, concorrentemente con il codice che il chiamante sta eseguendo.