La sintassi della chiamata di sistema per creare un nuovo thread è uguale a quella dei processi, ovvero ''fork()''. La semantica cambia invece sensibilmente. Il problema è il seguente: se il thread di un programma chiama una [@fork()@], verrà creato un nuovo processo con la copia di tutti i thread, o un processo pesante composto da quell'unico thread che aveva lanciato la fork? Dipende dal sistema operativo. Ad esempio nei sistemi UNIX viene data la possibilità di scegliere tra le due alternative fornendo due funzioni [@fork()@] distinte: quella che duplica tutti i thread e quella che duplica solo il thread che effettua la chiamata di sistema.

La funzione di esecuzione ''exec()'' riveste il thread di un nuovo codice, rimpiazzando quello di partenza. Anche in questo caso la sintassi è rimasta invariata rispetto alla corrispondente chiamata di sistema per i processi, come anche la semantica.\\

Se il kernel supporta nativamente tale schedulazione non ci sono problemi, ma in caso contrario? Una soluzione potrebbe essere mascherare i thread da processi, così che il sistema operativo possa sfruttare gli algoritmi che conosce e implementa per ottenere il multi-tasking. E' a questo scopo che in molti sistemi sono state introdotte delle strutture dati intermedie fra i thread a livello utente e quelli a livello kernel, detti ''processi leggeri'' (''lightweight process, LWP''). Dei processi detiene tutte quelle caratteristiche che lo rendono autonomo e passibile di context-switching, così da potervi applicare la schedulazione; non ha però un proprio spazio di indirizzamento, condividendo di fatto gran parte della memoria con gli altri thread (livello utente). Sull'altro livello, l'LWP appare alla libreria dei thread utente come una sorta di ''processore virtuale'' grazie al quale l'applicazione può schedulare l'esecuzione di un thread utente. Va infine ricordato che la mappatura "thread utente - processo leggero" segue il modello uno-a-uno.

* ''modello molti-a-uno'', che riunisce molti thread di livello utente in un unico flusso di controllo sul kernel. La gestione dei thread è fatta dalla libreria nello spazio utente, quindi sarà il programma utente a dover sincronizzare opportunamente i suoi thread interni in modo che il kernel thread che li gestise li veda come uno solo. Lo svantaggio di tale mappatura è che se uno dei thread in esecuzione si blocca (ad esempio per un I/O), verranno bloccati di conseguenza tutti gli altri thread che fanno parte del suo gruppo. Per fare un esempio, il thread kernel A gestisce i thread utente Alfa, Beta e Gamma. Se Beta fa un'I/O, si blocca in attesa del risultato. Bloccandosi Beta, anche A si blocca perché è proprio A a dover fornire l'I/O a Beta. Ma se A smazza l'I/O di Beta, allora Alfa e Gamma non possono fare altro che dormire, perché A, che dovrebbe gestirli, non può ascoltarli in quanto impegnato a dare retta all'I/O di Beta! Basta dunque una chiamata bloccante e tutto si impasta

* ''modello uno-a-uno'', che mappa ciascun thread utente in un kernel thread. Fornisce molta più concorrenza del modello precedente, permettendo ad un processo di andare in esecuzione nonostante un'eventuale chiamata bloccante da parte di un altro. Consente inoltre su sistemi multiprocessore che più thread siano eseguiti in parallelo su diversi processori. Lo svantaggio di tale modello è che la creazione di un thread utente richiede la creazione del corrispondente kernel thread, con un conseguente overhead di gestione che grava sul sistema operativo diminuendone proporzionalmente l'efficienza complessiva.

* ''modello molti-a-molti'', che raggruppa in vario modo i thread a livello utente verso un numero inferiore (o equivalente) di kernel thread. Tale numero può dipendere sia dall'applicazione che dalla macchina utilizzata. Con questo modello vengono superati entrambi i limiti dei due precedenti, ovvero non ho più i problemi di concorrenza del ''molti-a-uno'' né limiti nella creazione di thread utente come nell' ''uno-a-uno''. Col ''molti-a-molti'' posso infatti creare quanti thread voglio, che potranno comunque essere eseguiti in parallelo.

->Una variante popolare è quella del ''modello a due livelli'', che mappa molti thread di livello utente verso un numero più piccolo o equivalente di kernel thread, ma permette anche di associarne alcuni in modalità ''uno-a-uno''.

Se il processo tradizionale (detto ''pesante'') ha un solo thread che fa tutto, un processo ''multithread'' è caratterizzato da più flussi di esecuzione di istruzioni in parallelo, operanti contemporaneamente e con parte delle informazioni condivise in memoria centrale. In questo modo ogni thread svolgerà le proprie operazioni e potrà eventualmente trasmetterne i risultati a flussi diversi della computazione, proprio in virtù della condivisione dell'accesso allo stesso spazio di indirizzamento. Ovviamente andranno [@sincronizzati->SO-Sincronizzazione]] opportunamente, o potrei avere dati inconsistenti (perché ad esempio modificati da altri).

E' sulla base di queste necessità che nascono i '''thread''', ovvero ''un gruppo di flussi di esecuzione autonomo sullo stesso programma che accedono alla stessa porzione di memoria centrale''. Detto in altre parole, è un mini-processo che vive all'interno di un processo vero, autonomo dal punto di vista dell'esecuzione, ma con la stessa "base di dati" a cui attingere, ovvero quella del processo che lo ha generato.

Se il processo tradizionale (detto ''pesante'') ha un solo thread che fa tutto, un processo ''multithread'' è caratterizzato da più flussi di esecuzione di istruzioni in parallelo, operanti contemporaneamente e con parte delle informazioni condivise in memoria centrale. In questo modo ogni thread svolgerà le proprie operazioni e potrà eventualmente trasmetterne i risultati a flussi diversi della computazione, proprio in virtù della condivisione dell'accesso allo stesso spazio di indirizzamento. Ovvio che andranno sincronizzati opportunamente, o potrei avere dati inconsistenti (perché ad esempio modificati da altri), ma questa è un'altra storia.

Si può notare come, pur avendo in comune lo stesso codice, due thread diversi hanno comunque contesti specifici su cui operare (quindi registri e stack separati), in modo da poter eseguire operazioni diverse prese da parti diverse del codice. Se infatti condividessero anche stack e registri, finirebbero inevitabilmente per eseguire le stesse cose nello stesso momento.

* ''prontezza di risposta'', dato che l'eventuale disponibilità di thread liberi garantirà una maggiore rapidità nel servizio dell'utente. Ad esempio, un browser multithread può permettere all'utente l'interazione in un thread mentre un'immagine viene caricata da un altro;

* ''sfruttabili dai sistemi multiprocessore'', dove i thread possono essere eseguiti in parallelo su processori differenti, raggiungendo così una condivisione efficiente, nativa e diretta delle informazioni.

I [[processi->SO-Processi]] tradizionali sono programmi in esecuzione con un unico flusso di controllo, detto ''thread''. Ognuno di essi è un'entità autonoma, ciascuna con il proprio spazio di indirizzamento inaccessibile dagli altri. Ma se questa proprietà da un lato garantisce integrità e sicurezza, dall'altro può rappresentare un problema, soprattutto per quelle applicazioni ad alta disponibilità di servizio e basso tempo di risposta (come i server web), dove l'utente - o gli utenti - potrebbero richiedere l'esecuzione di più flussi di controllo nello stesso processo per attività simili.

Ad esempio ho un server web che accetta le richieste concorrenti di più client per le pagine web e tutti gli oggetti in esse contenute. Se fosse eseguito come un singolo processo, e quindi con un unico thread, allora riuscirebbe a servire un solo client per volta, facendo lievitare i tempi di attesa di tutti gli altri.\\
Una soluzione semplice potrebbe essere attivare tanti processi che erogano il servizio quante sono le richieste per lo stesso (ovviamente stiamo parlando di sistemi multiprogrammati e multitasking), ma anche in questo caso avrei svantaggi piuttosto rilevanti. In primo luogo sarebbe impossibile prevedere a priori il numero di richieste di accesso, e quindi quanti processi dovrò attivare? In secondo luogo avrei un sistema lento, con una gestione poco furba delle risorse. Se infatti al server web arrivassero più richieste per una stessa pagina, ogni volta il processo di servizio dovrebbe leggerla e inviarla al client, sprecando tempo e spazio.

Sarebbe dunque bello se operazioni similari su dati diversi operassero in modo più correlato, magari su un'area di memoria centrale condivisa a cui i processi possano accedere in modo nativo e naturale. In particolare, vorrei che le applicazioni rendessero disponibili i propri dati ai processi figli in modo semplice, senza doverli ogni volta ricopiare nei rispettivi spazi di indirizzamento, perché è una soluzione inefficiente.

E' sulla base di queste necessità che nascono i ''thread'', ovvero ''un gruppo di flussi di esecuzione autonomo sullo stesso programma che accedono alla stessa porzione di memoria centrale''. Detto in altre parole, è un mini-processo che vive all'interno di un processo vero, autonomo dal punto di vista dell'esecuzione, ma con la stessa "base di dati" a cui attingere, ovvero quella del processo che lo ha generato.

I [[processi]] tradizionali sono programmi in esecuzione con un unico flusso di controllo, detto ''thread''. Ognuno di essi è un'entità autonoma, ciascuna con il proprio spazio di indirizzamento inaccessibile dagli altri. Ma se questa proprietà da un lato garantisce integrità e sicurezza, dall'altro può rappresentare un problema, soprattutto per quelle applicazioni ad alta disponibilità di servizio e basso tempo di risposta (come i server web), dove l'utente - o gli utenti - potrebbero richiedere l'esecuzione di più flussi di controllo nello stesso processo per attività simili.

I processi tradizionali sono programmi in esecuzione con un unico flusso di controllo, detto ''thread''. Ognuno di essi è un'entità autonoma, ciascuna con il proprio spazio di indirizzamento inaccessibile dagli altri. Ma se questa proprietà da un lato garantisce integrità e sicurezza, dall'altro può rappresentare un problema, soprattutto per quelle applicazioni ad alta disponibilità di servizio e basso tempo di risposta (come i server web), dove l'utente - o gli utenti - potrebbero richiedere l'esecuzione di più flussi di controllo nello stesso processo per attività simili.

Se il kernel supporta nativamente tale schedulazione non ci sono problemi, ma in caso contrario? Una soluzione potrebbe essere mascherare i thread da processi, così che il sistema operativo possa sfruttare gli algoritmi che conosce e implementa per ottenere il multi-tasking. E' a questo scopo che in molti sistemi sono state introdotte delle strutture dati intermedie fra i thread a livello utente e quelli a livello kernel, detti ''processi leggeri'' (''lightweight process, LWP''). Pur essendo trattato e schedulato dal kernel come un processo,

???

!!!Sincronizzazione e comunicazione

!!!

* ''thread in pipeline'', dove ogni thread svolge una porzione del lavoro complessivo, essendo specializzato in un preciso sottoinsieme delle funzioni dell'elaborazione complessiva. Avviene dunque una suddivisione del lavoro, come in una catena di montaggio. Ottengo così una distribuzione dei lavori ed un throughput elevato, dal momento che ogni thread torna in attesa di soddisfare nuove richieste dopo il tempo minimale che impiega per svolgere la sua piccola sequenza di operazioni (il concetto è fare poche operazioni, ma spesso).

Va da sé che questi modelli si applicano su sistemi multithread. In un sistema operativo con supporto per soli processi pesanti, occorre simularli a livello utente all'interno di un processo utilizzando una libreria di livello utente.

* ''modello molti-a-molti'', che raggruppa in vario modo i thread a livello utente verso un numero inferiore (o equivalente) di kernel thread. Tale numero può dipendere sia dall'applicazione che dalla macchina utilizzata. Con questo modello vengono superati entrambi i limiti dei due precedenti, ovvero non ho più i problemi di concorrenza del ''molti-a-uno'' né limiti nella creazione di thread utente come nell' ''uno-a-uno''. Col ''molti-a-molti'' posso infatti creare quanti thread voglio, che potranno comunque essere eseguiti in parallelo.\\

Una variante popolare è quella del ''modello a due livelli'', che mappa molti thread di livello utente verso un numero più piccolo o equivalente di kernel thread, ma permette anche di associarne alcuni in modalità ''uno-a-uno''.

* ''modello molti-a-uno'', che riunisce molti thread di livello utente in un unico kernel thread

va detto che per realizzare un sistema multithread in un sistema operativo con supporto per soli processi pesanti, occorre simularli a livello utente all'interno di un processo utilizzando una libreria di livello utente.

!!!...al concetto di thread