Azienda Google per l'inclusione nel kernel di Linux, il primo set di patch con l'implementazione dei componenti necessari per garantire il funzionamento del modello di flussi M:N. L'iniziativa di Google è correlata all'apertura di un'API in fase di sviluppo a porte chiuse per il kernel di Linux, che garantisce il funzionamento del sottosistema multithread implementato nello spazio utente, che utilizza il modello di flussi M:N. Il sottosistema è utilizzato da Google per garantire il funzionamento dei servizi che richiedono minimi ritardi. La pianificazione e la gestione della distribuzione dei flussi avviene interamente nello spazio utente, consentendo quindi una significativa riduzione del numero di operazioni di cambio contesto grazie alla minimizzazione dell'esecuzione delle chiamate di sistema.
Per garantire il funzionamento di detto sottosistema a livello di kernel di Linux, è stata implementata l'API SwitchTo, che offre tre operazioni di base: wait, resume e swap (cambio). Per l'inclusione nel kernel, è stato proposto il codice di una nuova operazione FUTEX_SWAP, che integra , e fornisce una base per la creazione di librerie multithread nello spazio utente. FUTEX_SWAP può inoltre essere utilizzato per la trasmissione di messaggi tra i task, analogamente a RPC. Ad esempio, attualmente per trasmettere un messaggio tra i task è necessario effettuare almeno quattro chiamate a FUTEX_WAIT e FUTEX_WAKE, mentre l'utilizzo di FUTEX_SWAP consentirebbe di gestire il tutto con una sola operazione, che sarà eseguita da 5 a 10 volte più rapidamente.
Attualmente, nella pratica, sono principalmente utilizzati i modelli di flussi 1:1 e N:1. Il modello 1:1 è utilizzato in (thread POSIX) e , e implica una corrispondenza diretta tra un thread nello spazio utente e un thread (unità di pianificazione) a livello di kernel. Il modello N:1 è implementato in , spostando la gestione dei thread nello spazio utente e consentendo a N thread nello spazio utente di essere collegati a un singolo thread nel kernel, di cui il kernel non ha informazioni sui thread utente.
L'inconveniente principale del modello 1:1 sono i grandi costi aggiuntivi per il passaggio di contesto tra il nucleo e lo spazio utente. Il modello N:1 risolve questo problema, ma ne crea uno nuovo: poiché il flusso nel nucleo è un'unità indivisibile di pianificazione dell'esecuzione, i flussi utente legati a un flusso nel nucleo del sistema operativo non possono scalare su più core della CPU e risultano vincolati a un solo core della CPU.
Il modello M:N è un ibrido e elimina tutti gli inconvenienti sopra descritti grazie all'abbinamento di N flussi nello spazio utente a M flussi nel nucleo dell'OS, il che consente di ridurre sia i costi associati al passaggio di contesto sia di garantire la scalabilità sui core della CPU. Il prezzo di questa opzione è un notevole aumento della complessità dell'implementazione dello scheduler dei flussi nello spazio utente e la necessità di meccanismi di coordinamento delle azioni con lo scheduler del nucleo.
Fonte: opennet.ru
