Cosa rende esattamente il processo Erlang, filo verde, coroutine "più leggero" del thread kernel?Che dire del cambio di contesto che è pesante?[duplicare]

Question

Possibile duplicato:
Tecnicamente perché i processi in Erlang sono più efficienti del sistema operativothread?

Ogni volta che vengono menzionati processi Erlang, thread verdi o coroutine, vengono sempre descritti come "leggeri" rispetto ai thread del kernel.La ragione solitamente fornita è che i thread del kernel implicano il cambio di contesto che è lento.

Ma che dire esattamente del cambio di contesto lento?E quanto è più lento rispetto al cambio di thread verdi in userland?

Il cambio di contesto è il principale (unico?) fattore che tiene conto della differenza di prestazioni e consumo di memoria tra un programma basato su eventi come Nignx e un programma multi-elaborazione come Apache?

Answer 1

Il cambio di contesto su sistemi operativi preemptive, monolitici e multitasking coinvolge uno dei due percorsi, o un rendimento implicito allo scheduler tramite una chiamata al servizio di sistema (sleep, mutex acquisito, attesa di un evento, blocco dell'I / O) o tramite un interrupt e lo scheduler decide di scambiare le attività in esecuzione.

Quando un'attività viene scambiata dallo scheduler, accadono alcune cose pesanti:

• Tutta l'azione avviene come parte del kernel del sistema operativo, in esecuzione con un elevato livello di privilegio. Ogni azione viene controllata (o dovrebbe esserlo) per garantire che le decisioni prese dallo scheduler non concedano a un'attività alcun privilegio aggiuntivo (si pensi all'exploit root locale)
• Gli spazi degli indirizzi dei processi in modalità utente vengono scambiati. Ciò si traduce nel gestore della memoria che si preoccupa dei layout della tabella di pagina e carica una nuova directory base in un registro di controllo.
• Ciò significa anche che i dati conservati nella cache della CPU potrebbero essere abbattuti ed eliminati. Questo farebbe schifo se il tuo compito avesse appena avuto accesso a un mucchio di cose usate di frequente, quindi il contesto cambiato e "perso" (al prossimo accesso dovrebbe [probabilmente] essere recuperato di nuovo dalla memoria principale)
• A seconda di come si intercetta nel kernel, è quindi necessario intercettare il kernel. Se si effettua una chiamata di sistema, ad esempio, la CPU eseguirà una serie di passaggi molto precisi per passare al codice in esecuzione nel kernel e quindi, all'uscita, annullerà quei passaggi. Questi passaggi sono più complicati che effettuare una chiamata di funzione a un altro modulo nel programma, quindi richiedono più tempo.

Un'attività di thread verde è piuttosto semplice, a quanto ho capito. Un dispatcher in modalità utente indirizza una coroutine da eseguire fino a quando la coroutine non cede. Alcune differenze sopra:

• Nessuno dell'invio di coroutine avviene in modalità kernel, infatti l'invio di thread verdi generalmente non ha bisogno di coinvolgere alcun servizio del sistema operativo o alcun servizio di blocco del sistema operativo. Quindi tutto questo può accadere senza alcun cambio di contesto o alcuna traduzione utente / kernel.
• Un filo verde non è programmato preventivamente, o addirittura annullato del tutto dal gestore del thread verde, è pianificato in modo cooperativo. Questo è buono e cattivo, ma con routine ben scritte, generalmente buone. Ogni attività fa esattamente ciò di cui ha bisogno e quindi si ritrova nel dispatcher, ma senza alcun sovraccarico di scambio di contesto.
• I thread verdi condividono il loro spazio degli indirizzi (per quanto ne so). Nessuno scambio dello spazio degli indirizzi avviene sui cambi di contesto. Gli stack sono (per quanto ne so) scambiati, ma quegli stack sono gestiti dal dispatcher e anche lo scambio di uno stack è una semplice scrittura in un registro. Anche lo scambio di uno stack è un'operazione non privilegiata.

In breve, un cambio di contesto in modalità utente implica alcune chiamate di libreria e la scrittura nel registro del puntatore dello stack. Un cambio di contesto in modalità kernel implica interruzioni, transizione utente / kernel e comportamenti a livello di sistema come modifiche dello stato dello spazio degli indirizzi e svuotamenti della cache.