Processo leggero - Light-weight process

Per i processi leggeri in Erlang, vedere Erlang (linguaggio di programmazione) § Concorrenza e orientamento alla distribuzione .

Nei sistemi operativi per computer , un processo leggero ( LWP ) è un mezzo per ottenere il multitasking . Nel significato tradizionale del termine, utilizzato in Unix System V e Solaris , un LWP viene eseguito nello spazio utente su un singolo thread del kernel e condivide il suo spazio di indirizzi e le risorse di sistema con altri LWP all'interno dello stesso processo . Più thread a livello di utente , gestiti da una libreria di thread, possono essere posizionati sopra uno o più LWP, consentendo di eseguire il multitasking a livello di utente, il che può avere alcuni vantaggi in termini di prestazioni.

In alcuni sistemi operativi non esiste un livello LWP separato tra i thread del kernel e i thread dell'utente. Ciò significa che i thread utente vengono implementati direttamente sopra i thread del kernel. In tali contesti, il termine "processo leggero" si riferisce tipicamente ai thread del kernel e il termine "thread" può fare riferimento ai thread dell'utente. Su Linux , i thread utente vengono implementati consentendo a determinati processi di condividere risorse, il che a volte porta questi processi a essere chiamati "processi leggeri". Allo stesso modo, nella versione 4 di SunOS in poi (prima di Solaris ) il "processo leggero" si riferiva ai thread dell'utente.

Discussioni del kernel

I thread del kernel sono gestiti interamente dal kernel . Non è necessario che siano associati a un processo; un kernel può crearli ogni volta che ha bisogno di eseguire un compito particolare. I thread del kernel non possono essere eseguiti in modalità utente. Gli LWP (nei sistemi in cui sono un livello separato) si legano ai thread del kernel e forniscono un contesto a livello di utente. Ciò include un collegamento alle risorse condivise del processo a cui appartiene LWP. Quando un LWP viene sospeso, deve archiviare i propri registri a livello di utente fino a quando non viene ripreso e anche il thread del kernel sottostante deve archiviare i propri registri a livello di kernel.

Prestazione

Gli LWP sono più lenti e più costosi da creare rispetto ai thread utente. Ogni volta che viene creato un LWP, è necessario prima effettuare una chiamata di sistema per creare un thread del kernel corrispondente, causando il passaggio alla modalità kernel. Questi cambi di modalità in genere comportano la copia dei parametri tra il kernel e lo spazio utente, inoltre il kernel potrebbe aver bisogno di passaggi aggiuntivi per verificare i parametri per verificare il comportamento non valido. Un cambio di contesto tra LWP significa che l'LWP che viene anticipato deve salvare i suoi registri, quindi entrare in modalità kernel per consentire al thread del kernel di salvare i suoi registri e l'LWP che viene pianificato deve ripristinare il kernel e i registri utente separatamente anche.

Per questo motivo, alcune librerie di thread a livello utente consentono l'implementazione di più thread utente su LWP. I thread utente possono essere creati, distrutti, sincronizzati e commutati interamente nello spazio utente senza chiamate di sistema e passare alla modalità kernel. Ciò fornisce un miglioramento significativo delle prestazioni nel tempo di creazione del thread e nei cambi di contesto. Tuttavia, ci sono difficoltà nell'implementare uno scheduler di thread a livello utente che funzioni bene insieme al kernel.

Attivazione del programmatore

Mentre la libreria di threading utente pianificherà i thread utente, il kernel pianificherà gli LWP sottostanti. Senza coordinamento tra il kernel e la libreria di thread, il kernel può prendere decisioni di pianificazione non ottimali. Inoltre, è possibile che si verifichino casi di deadlock quando i thread utente distribuiti su più LWP tentano di acquisire le stesse risorse utilizzate da un altro thread utente che non è attualmente in esecuzione.

Una soluzione a questo problema è l'attivazione dello scheduler. Questo è un metodo per la cooperazione tra il kernel e la libreria di thread. Il kernel notifica allo scheduler della libreria di thread di determinati eventi (come quando un thread sta per bloccarsi) e la libreria di thread può prendere una decisione su quale azione intraprendere. La chiamata di notifica dal kernel è chiamata "upcall".

Una libreria a livello utente non ha alcun controllo sul meccanismo sottostante, riceve solo notifiche dal kernel e pianifica i thread utente sugli LWP disponibili, non sui processori. Lo scheduler del kernel decide quindi come schedulare gli LWP sui processori. Ciò significa che gli LWP possono essere visti dalla libreria di thread come "processori virtuali".

Supportare i sistemi operativi

Solaris ha implementato un livello LWP separato dalla versione 2.2. Prima della versione 9, Solaris consentiva una mappatura molti a molti tra LWP e thread utente. Tuttavia, questo è stato ritirato a causa delle complessità introdotte e dei miglioramenti delle prestazioni allo scheduler del kernel.

UNIX System V e i suoi moderni derivati IRIX , SCO OpenServer , HP-UX e IBM AIX consentono una mappatura molti a molti tra thread utente e LWP.

implementazioni

Guarda anche

Riferimenti

link esterno