Google per l'inclusione nel kernel Linux il primo set di patch con l'implementazione dei componenti necessari per garantire il funzionamento del modello di threading M: N. L'iniziativa di Google è legata all'apertura di un'API sviluppata a porte chiuse per il kernel Linux, che fornisce un sottosistema multi-thread implementato nello spazio utente che utilizza il modello di threading M:N. Il sottosistema viene utilizzato da Google per fornire servizi che richiedono ritardi minimi. La pianificazione e la gestione della distribuzione dei thread viene eseguita interamente nello spazio utente, il che può ridurre significativamente il numero di cambi di contesto riducendo al minimo l'esecuzione delle chiamate di sistema.
Per garantire il funzionamento di questo sottosistema, l'API SwitchTo è stata implementata a livello di kernel Linux, offrendo tre operazioni di base: attesa, ripresa e scambio (commutazione). Per l'inclusione nel kernel, viene proposto un codice per una nuova operazione FUTEX_SWAP, integrando e fornisce un framework per la creazione di librerie dello spazio utente multi-thread. FUTEX_SWAP può anche essere utilizzato per passare messaggi tra attività, in modo simile a RPC. Ad esempio, al momento, per trasferire un messaggio tra attività, sono necessarie almeno quattro chiamate a FUTEX_WAIT e FUTEX_WAKE, mentre l'utilizzo di FUTEX_SWAP consentirà di completare un'operazione 5-10 volte più velocemente.
Attualmente, nella pratica vengono utilizzati principalmente i modelli di flusso 1:1 e N:1. Viene utilizzato il modello 1:1 (thread POSIX) e e implica una mappatura diretta di un thread dello spazio utente a un thread (unità di pianificazione dell'esecuzione) a livello di kernel. Il modello N:1 è implementato in , porta la pianificazione dei thread nello spazio utente e consente a N thread dello spazio utente di associarsi a un singolo thread nel kernel, senza che il kernel sappia dei thread utente.
Il principale svantaggio del modello 1:1 è il grande sovraccarico del cambio di contesto tra il kernel e lo spazio utente. Il modello N:1 risolve questo problema, ma ne crea uno nuovo: poiché un thread nel kernel è un'unità indivisibile di pianificazione dell'esecuzione, i thread utente associati a un singolo thread nel kernel del sistema operativo non possono scalare tra i core della CPU e diventare associati a un singolo core della CPU.
Il modello M:N è ibrido e affronta tutti gli svantaggi di cui sopra mappando N thread dello spazio utente su M thread del kernel, riducendo sia l'overhead del cambio di contesto che il ridimensionamento tra i core della CPU. Il prezzo di questa opzione è la grande complicazione dell'implementazione dello scheduler dei thread nello spazio utente e la necessità di meccanismi per coordinare le azioni con lo scheduler del kernel.
Fonte: opennet.ru