Introduzione ai processi e thread in ambiente Linux. Come si creano, come si eseguono e come funzionano.

1. Processi 20/02/19
• Cos’è un processo?
Un processo è un’attività di esecuzione di un programma in modo
sequenziale, quindi un compito che il processore dell’elaboratore deve
portare a termine su richiesta dell’utente. Il processo è l’entità utilizzata dal
sistema operativo per rappresentare l’esecuzione di un programma. È
un’attività attiva mentre il programma è un’attività passiva che descrive
soltanto mediante le istruzioni ciò che bisogna eseguire. Un processo è
identificato da un PID (Process IDentifier) che lo identifica univocamente.
Precisamente il processo ha un insieme di attributi contenuti nel PCB
(Process Control Block), una tabella con diversi attributi che ne descrivono
l’esistenza, tali attributi sono ereditati dalla chiamata fork() ed alcuni di
questi sono modificati con l’esecuzione della exec(). Un processo può essere
eseguito sia in background che in foreground. Ogni processo associa almeno
un thread (se stesso).
• Come si crea un processo?
Un processo si crea mediante l’esecuzione della chiamata di sistema fork().
La fork() crea in memoria una copia di se stesso, dove la copia prende il
nome di processo figlio, mentre l’originale si chiama padre. La fork realizza
un processo mediante la copia di uno esistente, la differenza tra i due si basa
sull’uso del valore di ritorno del PID (Il PID è un identificatore univoco di
ogni singolo processo). Il processo creato prosegue la sua esecuzione
indipendentemente dal padre, che avrà un pid >0, mentre il figlio =0,
altrimenti valore <0 se la fork non è riuscita.Con l’esecuzione di questa sys
call si crea un nuovo spazio di indirizzamento per il figlio. Il processo figlio
avrà comunque tutte le variabili e i comandi del padre ma effettuerà una
diramazione quando giunge alla condizione di verifica del pid. La fork() è
una chiamata costosa per il sistema operativo perché richiede l’allocazione di
molte risorse di un nuovo PCB. Quando si crea un processo si associa ad
esso almeno un thread (se stesso).
• Come termina un processo?
Un processo può terminare la propria esecuzione in 4 modi:
• Termina correttamente.
• Condizione di errore rilevata dal programma con conseguente
uscita (Esempio: File in input non presente).

2. • Errore fatale che ha causato una trap gestita dal sistema operativo
che termina il processo.
• Killato da un altro processo mediante l’uso delle sys call.
• Stati di un processo?
Un processo ha una propria ciclo “vitale”. Nel momento della creazione si trova
nello stato di New, uno stato che potrebbe tenere il processo abbastanza a lungo
fin quando non gli vengono concesse le risorse.
Dopo l’allocazione delle risorse il processo prosegue nello stato di Ready. Tale
stato è temporaneo e il processo attende che gli venga assegnata la CPU.
Quando la CPU è stata assegnata passa nello stato di Running e se termina
volontariamente passa nello stato di Termined, dove il sistema operativo ne
tiene ancora traccia per avere informazioni sulla terminazione. Quindi
l’esecuzione normale avviene seguendo la procedura:
New->Read->Running->Termined
Un processo può “capitare” nello stato di Waiting in caso esso necessiti del
verificarsi di un dato evento. Nel momento in cui la condizione è soddisfatta
ritorna nello stato di Ready in attesa della CPU.
Un processo dagli stati: Ready, Running, Waiting può terminare direttamente in
caso di problematiche di qualsiasi genere, quali sys.call bloccanti o mancanza di
file, problemi di accessi ed altro.
• Chi schedula l’esecuzione dei processi?
I processi sono selezionati dallo Scheduler, componente del sistema
operativo che si occupa della scelta del processo da portare dallo stato di
Ready a Running. Lo scheduler è realizzato su una politica di scheduling,

3. ovvero su una scelta di quale algoritmo usare per la scelta del processo
(Esempio:FCFS, SJF, SRJF). Ma vedremo tale argomento approfondito
successivamente. Praticamente il Dispatcher si occupa del context switch,
ovvero dell’assegnazione della CPU al processo. Il Dispatcher e lo Scheduler
sono due entità separate ove lo scheduler realizza la politica, il dispatcher
l’esegue.
• Come avviene il cambio di un processo nella CPU e la PCB?
Ogni processo associa la PCB, ovvero il suo blocco contenente attributi che
ne descrivono lo stato. La PCB contiene informazioni relative ai registri
della CPU, allo stato del processo (Ready, Running...) , alla sua priorità, al
suo PID od ID, al suo gruppo di appartenenza, al suo parent process, al
tempo che ha trascorso con la CPU, al suo User ID e Group ID (Quest’ultimi
sono informazioni utili per la protezione). Quando si cambia processo non si
fa altro che salvare lo stato dei registri nella PCB e ripristinarlo quando la
CPU viene riassegnata a tale processo. Possiamo immaginare quindi una
coda di PCB che realizzano la coda dei processi pronti per l’esecuzione.
Threads
• Cosa sono i threads?
I processi sono un “astrazione” realizzata per utilizzare al meglio le risorse e
la CPU, più processi attivi contemporaneamente possono essere visti come
in competizione tra loro, è compito del sistema operativo garantire la non
interferenza dei processi. Un insieme di processi può cooperare per
raggiungere un obiettivo comune, ciò è possibile ma dispendioso soprattutto
per via del frequente context switch. Da qui l’idea della creazione dei thread,
che non è altro che la suddivisione di un processo in più filoni che vengono
eseguiti concorrentemente. Esistono diverse implementazioni dei thread, si
possono avere più processi con ognuno un singolo thread (spazio di memoria
separato) o un processo con più threads (condividono il codice e i dati).
Come per i processi anche per i thread viene mantenuta una TCB (Thread
control block) che contiene dati quali Stack Pointer, il puntatore alla PCB del

4. processo, Program Counter ed il suo stato. Ogni thread è caratterizzato dal
suo stato (Ready, Running, Waiting), ciò che condividono più threads di un
singolo processo è lo spazio di indirizzamento.
• Quali sono i vantaggi dei threads?
I threads condividendo lo spazio di indirizzamento possono accedere tutti e
modificare le stesse variabili. La creazione di un threads è anche 100 volte
più veloce della creazione di un processo. Inoltre permettono di poter
eseguire più azioni contemporaneamente evitando quindi di stoppare
l’applicazione completa in attesa di un evento. La comunicazione tra
processi richiede un passaggio alla Kernel Mode (proprio per questioni di
sicurezza), e ciò è molto dispendioso da punto di vista delle prestazioni,
mentre i threads condividendo la memoria possono comunicare in modo
semplice e rapido.
• Come si implementa un thread?
I thread possono essere implementati in due modi:
➢ User Space
➢ Kernel Space
Implementando i thread nello User Space il kernel non ne è a conoscenza
dell’esistenza. Vengono implementati mediante librerie e la loro creazione e
gestione non è affidata al sistema operativo. La schedulazione è differente
perché la CPU è assegnata al processo, il quale ha all’interno dello spazio di
indirizzi del processo la TCB, così assegna il tempo concesso al processo ai suoi
thread pronti. Ammettiamo di avere un processo P con tanti thread T1,T2...
La CPU viene assegnata a P e ad uno dei suoi processi T nello stato di ready, se
il thread lancia una primitiva di sincronizzazione come thread_wait, accade che
automaticamente si salva lo stato del thread attuale e ne viene scelto un altro da
far girare, se non sono presenti thread disponibili si termina il processo e la
CPU viene assegnata ad un altro.
Vantaggi thread a livello utente:
➢ Costo context switch basso
➢ Implementazione su qualsiasi sistema operativo
➢ Scelta della politica di scheduling
Svantaggi:
➢ Le system call bloccanti di un thread possono bloccare l’intero processo
➢ Solo un thread running per processo

5. Implementando un thread nella Kenel Space comporta una gestione da parte del
sistema operativo, che ora gestiscono Kernel nello scheduler e non processi
come prima. Si usano ora le system call per la creazione e gestione
Vantaggi:
➢ Più thread in running
➢ System call bloccanti non sono un probleam
Svantaggi:
➢ Costoso context switch
➢ Numero limitato di thread data la predisposizione di una struttura per la
gestione degli ultimi.
Per errori di informazioni, concettuali o ortografici
inviare mail a info@titanuslab.com
File realizzato da Vincenzo Morrone.
LinkedIn: https://www.linkedin.com/in/titanuslab
Facebook: https://www.facebook.com/titanuslab/
Sito web: https://titanuslab.com