Qual è la differenza tra un processo e un thread?

Ecco l'analogia che uso nello sviluppo del kernel Linux. I processi sono l'astrazione dei programmi in esecuzione: Un'immagine binaria, memoria virtualizzata, varie risorse del kernel, un contesto di sicurezza associato, e così via. I thread sono l'unità di esecuzione in un processo: Un processore virtualizzato, uno stack e lo stato del programma. Detto in altro modo, i processi sono binari in esecuzione e i thread sono la più piccola unità di esecuzione programmabile da un sistema operativo.

Un processo contiene uno o più thread. Nei processi a thread singolo, il processo contiene un thread. Si può dire che il thread è il processo - c'è una cosa in corso. Nei processi multithreaded, il processo contiene più di un thread - c'è più di una cosa in corso.

Le due principali astrazioni virtualizzate nei sistemi operativi moderni sono la memoria virtualizzata e un processore virtualizzato. Entrambi danno l'illusione ai processi in esecuzione di essere i soli a consumare le risorse della macchina. La memoria virtualizzata dà ai processi una visione unica della memoria che si rifà senza soluzione di continuità alla RAM fisica o allo storage su disco (spazio di swap). Un processore virtualizzato permette ai processi di agire come se fossero eseguiti da soli su un processore, quando in realtà più processi sono in multitasking su più processori.

La memoria virtualizzata è associata al processo e non al thread. Così, i thread condividono uno spazio di indirizzi di memoria. Al contrario, un processore virtualizzato distinto è associato ad ogni thread. Ogni thread è un'entità pianificabile indipendente.

Qual è il punto? Ovviamente abbiamo bisogno di processi. Ma perché introdurre il concetto separato di thread e permettere processi multithread? Ci sono quattro benefici primari del multithreading:

• Astrazione della programmazione. Dividere il lavoro e assegnare ogni divisione a un'unità di esecuzione (un thread) è un approccio naturale a molti problemi. I pattern di programmazione che utilizzano questo approccio includono i pattern reactor, thread-per-connection e thread pool. Alcuni, tuttavia, vedono i thread come un anti-pattern. L'inimitabile Alan Cox ha riassunto bene questo concetto con la citazione, "i thread sono per le persone che non possono programmare macchine a stati". Nelle macchine con processori multipli, i thread forniscono un modo efficiente per ottenere un vero parallelismo. Poiché ogni thread riceve il proprio processore virtualizzato ed è un'entità pianificabile indipendentemente, più thread possono essere eseguiti su più processori allo stesso tempo, migliorando il throughput di un sistema. Nella misura in cui i thread sono usati per ottenere il parallelismo - cioè, non ci sono più thread che processori - la frase "i thread sono per persone che non sanno programmare macchine a stati" non si applica.
• Blocco dell'I/O. Senza thread, il blocco dell'I/O blocca l'intero processo. Questo può essere dannoso sia per il throughput che per la latenza. In un processo multithreaded, i singoli thread possono bloccarsi, aspettando l'I/O, mentre altri thread fanno progressi. L'I/O asincrono e non bloccante sono soluzioni alternative ai thread per questo problema.
  
• Risparmio di memoria. I thread forniscono un modo efficiente per condividere la memoria ma utilizzare più unità di esecuzione. In questo modo sono un'alternativa ai processi multipli.
  

Il costo di questi benefici del threading sono una maggiore complessità sotto forma di necessità di gestire la concorrenza attraverso meccanismi come mutex e variabili di condizione. Data la crescente tendenza verso processori con core multipli e sistemi con processori multipli, il threading è destinato a diventare uno strumento sempre più importante nella programmazione di sistema.