In che modo i thread a livello utente (ULT) e i thread a livello kernel (KLT) differiscono rispetto all'esecuzione simultanea?

Question

Ecco cosa ho capito; Si prega di correggere/aggiungere ad esso:

In ULT puro, il processo multithreading esegue la pianificazione del thread. Quindi, il kernel in sostanza non si accorge della differenza e lo considera un processo a thread singolo. Se un thread effettua una chiamata di sistema di blocco, l'intero processo viene bloccato. Anche su un processore multicore, solo un thread del processo verrebbe eseguito alla volta, a meno che il processo non sia bloccato. Non sono sicuro di come gli ULT siano di grande aiuto.

In KLT puri, anche se un thread è bloccato, il kernel pianifica un altro thread (pronto) dello stesso processo. (In caso di KLT puri, suppongo che il kernel crei tutti i thread del processo.)

Inoltre, utilizzando una combinazione di ULT e KLT, come vengono mappati gli ULT in KLT?

Answer 1

L'analisi è corretta. Il kernel del sistema operativo non conosce i thread a livello utente. Dal suo punto di vista, un processo è una scatola nera opaca che occasionalmente effettua chiamate di sistema. Di conseguenza, se quel programma ha 100.000 thread a livello utente ma solo un thread del kernel, allora il processo può eseguire solo un thread a livello utente alla volta perché c'è un solo thread a livello kernel ad esso associato. D'altra parte, se un processo ha più thread a livello kernel, può eseguire più comandi in parallelo se esiste una macchina multicore.

Un comune compromesso tra questi è quello di avere un programma che richiede un numero fisso di thread a livello di kernel, quindi un proprio scheduler di thread divvy i thread a livello utente su questi thread a livello di kernel come appropriato. In questo modo, più ULT possono essere eseguiti in parallelo e il programma può avere un controllo dettagliato sul modo in cui i thread vengono eseguiti.

Per quanto riguarda il funzionamento di questa mappatura, esistono diversi schemi. Si può immaginare che il programma utente utilizzi uno qualsiasi dei più diversi sistemi di pianificazione. In realtà, se si fa questa sostituzione:

kernel thread < ---> nucleo processore

filo utente < ---> Kernel filo

Poi ogni schema il sistema operativo potrebbe usare per mappare i thread del kernel sui core potrebbe anche essere usato per mappare i thread a livello utente nei thread a livello kernel.

Spero che questo aiuti!

Answer 2

Prima di tutto, la risposta di templatetypedef è bella; Volevo semplicemente estendere la sua risposta un po '.

C'è un settore che ho sentito il bisogno di espandere un po ': combinazioni di ULT e KLT. Per comprendere l'importanza (quale etichetta Wikipedia hybrid threading), considerare i seguenti esempi:

Considerare un programma multi-thread (più KLT) dove ci sono più KLT dei nuclei logici disponibili. Per utilizzare in modo efficiente ogni core, come hai detto, vuoi che lo scheduler estrae i KLT che stanno bloccando quelli che sono pronti e non bloccano. Ciò garantisce che il core stia riducendo il tempo di inattività. Sfortunatamente, il passaggio a KLT è costoso per lo scheduler e consuma una quantità relativamente grande di tempo della CPU.

Questa è un'area in cui il threading ibrido può essere utile. Considera un programma multi-thread con più KLT e ULT. Analogamente a quanto indicato in templatetypedef, è possibile eseguire solo un ULT alla volta per ogni KLT. Se un ULT sta bloccando, vogliamo comunque spegnerlo per uno che non stia bloccando. Fortunatamente, gli ULT sono molto più leggeri di quelli di KLT, nel senso che ci sono meno risorse assegnate a un ULT e non richiedono alcuna interazione con lo scheduler del kernel. Essenzialmente, è quasi sempre più rapido passare a ULT piuttosto che spegnere KLT. Di conseguenza, siamo in grado di ridurre significativamente i tempi di inattività dei nuclei rispetto al primo esempio.

Ora, ovviamente, tutto questo dipende dalla libreria di thread utilizzata per implementare gli ULT. Ci sono due modi (che posso inventare) per "mappare" gli ULT ai KLT.

1. Una collezione di ULT di per tutti di KLT

   Questa situazione è ideale su un sistema di memoria condivisa. Esiste essenzialmente un "pool" di ULT a cui ogni KLT ha accesso. Idealmente, lo scheduler della libreria di thread assegnerebbe gli ULT a ciascun KLT su richiesta, contrariamente al KLT che accede al pool individualmente. Il più tardi potrebbe causare condizioni di gara o deadlock se non implementato con serrature o qualcosa di simile.

2. Una collezione di ULT di per ogni KLT (Qthreads)

   Questa situazione è ideale in un sistema di memoria distribuita. Ogni KLT avrebbe una collezione di ULT da eseguire. Lo svantaggio è che l'utente (o la libreria di threading) dovrebbe dividere l'ULT tra i KLT. Ciò potrebbe causare uno squilibrio del carico in quanto non è garantito che tutti gli ULT avranno la stessa quantità di lavoro da completare e completare all'incirca nello stesso tempo. La soluzione a questo sta permettendo la migrazione ULT; cioè, migrando ULT tra i KLT.