Google per includere nel kernel Linux il primo insieme di patch con l'implementazione dei componenti necessari per il funzionamento del modello di thread M:N. L'iniziativa di Google è legata all'apertura di un'API sviluppata a porte chiuse per il kernel Linux, che supporta il sottosistema multithreading implementato nello spazio utente, utilizzando il modello di thread M:N. Questo sottosistema è utilizzato da Google per garantire il funzionamento dei servizi che richiedono latenze minime. La pianificazione e la gestione della distribuzione dei thread vengono effettuate interamente nello spazio utente, il che consente di ridurre significativamente il numero di operazioni di switching del contesto, minimizzando l'esecuzione delle chiamate di sistema.
Per garantire il funzionamento di questo sottosistema a livello di kernel Linux, è stata implementata l'API SwitchTo, che offre tre operazioni fondamentali: wait, resume e swap (switching). È stato proposto del codice per una nuova operazione FUTEX_SWAP, che integra , e fornisce la base per la creazione di librerie multithread nel livello utente. FUTEX_SWAP può anche essere utilizzato per la comunicazione tra i task, in modo simile a RPC. Ad esempio, attualmente, per inviare un messaggio tra i task sono necessarie almeno quattro chiamate a FUTEX_WAIT e FUTEX_WAKE, mentre l'uso di FUTEX_SWAP permetterà di ridurre a un'unica operazione, che sarà eseguita da 5 a 10 volte più velocemente.
Attualmente, nella pratica, vengono utilizzati principalmente modelli di thread 1:1 e N:1. Il modello 1:1 è utilizzato in (thread POSIX) e , e implica una corrispondenza diretta tra un thread nel livello utente e un thread (unità di pianificazione) a livello di kernel. Il modello N:1 è implementato in , trasferendo la gestione dei thread nel livello utente e consentendo a N thread nel livello utente di essere legati a un solo thread nel kernel, mentre il kernel non ha informazioni sui thread utente.
Il principale svantaggio del modello 1:1 sono gli elevati costi di commutazione del contesto tra il core e lo spazio utente. Il modello N:1 risolve questo problema, ma ne crea uno nuovo: poiché il flusso nel kernel è un'unità di pianificazione indivisibile, i flussi utente legati a un flusso nel kernel del sistema operativo non possono scalare tra i core CPU e rimangono bloccati su un singolo core CPU.
Il modello M:N è ibrido e elimina tutti i difetti sopra descritti grazie all'abbinamento di N flussi nello spazio utente con M flussi nel kernel OS, permettendo sia di ridurre i costi di commutazione del contesto sia di garantire la scalabilità tra i core CPU. Il prezzo di questa opzione è una complicazione notevole nell'implementazione del pianificatore di flussi nello spazio utente e la necessità di meccanismi di coordinamento con il pianificatore del kernel.
Fonte: opennet.ru
