Tranne il fatto che scrivere uno scheduler di userspace è difficile, quali sono gli svantaggi di M: N threading / thread verdi?

1

Recentemente ho imparato a conoscere i diversi modi in cui le lingue gestiscono la concorrenza sotto il cofano e vorrei saperne un po 'di più sulle carenze del threading M: N. Per favore perdonami se ho dei fatti sbagliati nei paragrafi seguenti.

Comprendo i loop di eventi (almeno lo stile del ciclo di eventi utilizzato in un nodo simile alla lingua) e in che modo gli svantaggi principali sono la scrittura di codice in uno stile asincrono, un sacco di callback nidificati, non scalabile in più di un core (senza creare più processi), le attività ad alta intensità di CPU rallentano il ciclo e questa logica complessa finisce per far crescere lo stack delle chiamate molto. Il vantaggio, naturalmente, è che i problemi con il threading sono, per la maggior parte, astratti.

Ho visto M: N essere pubblicizzato come la soluzione ai problemi del ciclo degli eventi, e nella mia esperienza personale con alcuni Erlang e Go è stato per lo più vero.

Ora la mia domanda è, indipendentemente dalle sfumature delle diverse VM esistenti e dai linguaggi di programmazione (non voglio che questa sia una discussione Node vs Go vs Erlang), ci sono degli svantaggi inerenti a un modello M: N dato che hai un programmatore perfettamente scritto? Qualcosa di simile agli svantaggi che ho elencato sopra sui loop di eventi.

    
posta m0meni 30.09.2016 - 14:33
fonte

1 risposta

5

Uno svantaggio significativo con i thread MxN è relativo al blocco dell'I / O.

Se il sistema ha un I / O di blocco, i thread del kernel (N) possono essere bloccati. Quindi, supponendo che tu abbia 4 processori e usi N = 4, l'applicazione potrebbe perdere l'accesso a un processore per la durata dell'operazione di I / O di blocco.

Questa non è tanto una proprietà dello scheduler stesso, ma dell'interazione del codice utente con il sistema operativo.

Nel seguente testo , LWP è un processo leggero equivalente a un thread del kernel.

Scheduler Activation

Prior to Solaris 2.6 software, the kernel used a special signal, SIGWAITING, to inform the threads library that all LWPs were blocked in the kernel. This gave the library the opportunity to create another LWP so it could to continue to run other, nonblocking threads. In Solaris 2.6 software, this mechanism was augmented by the preferential use of a “door upcall.” Essentially, this involves the kernel being able to call into the user-level thread scheduler to adjust the number of LWPs in the process’ pool of LWPs. This door mechanism is more efficient than a signal, but if necessary, Solaris 2.6 software falls back to using the SIGWAITING mechanism.

In questo testo, non viene menzionato come eseguire la rispettiva riduzione dei thread N come sarebbe appropriato quando il thread di blocco viene sbloccato. Basti dire che questo è complicato.

I problemi con il blocco degli I / O possono essere evitati usando sempre l'I / O non bloccante e chiedendo all'utilità di pianificazione di eseguire un thread M differente sul thread N ora disponibile quando si esegue la richiesta I / O asincrona. Un livello di libreria potrebbe tradurre le chiamate di blocco in chiamate non bloccanti che cooperano con lo scheduler MxN e il meccanismo di completamento degli I / O asincroni. Apparentemente Erlang fa questo .

I potenziali problemi riguardano anche la priorità del thread con MxN, in quanto il kernel vede solo i thread N e i thread M sono specifici del processo. Quindi, nessuno vede tutti i thread M insieme su tutti i processi, mentre con i thread 1x1, il kernel vede i thread tutti insieme e quindi ha la vista più ampia per prendere le decisioni più equilibrate.

Credo che questo sia mitigato se esiste un solo processo reale (ad esempio una macchina virtuale Erlang) sul sistema.

Una storia dei trade-off nel corso degli anni di sviluppo del sistema operativo sarebbe interessante da digerire. Mi sembra che Solaris abbia implementato i thread MxN abbastanza presto, ma in seguito è passato a 1x1 riducendo il costo dei thread del kernel.

    
risposta data 30.09.2016 - 19:30
fonte

Leggi altre domande sui tag