Compania Google pentru a include în kernelul Linux primul set de patch-uri cu implementarea componentelor necesare pentru a permite funcționarea modelului de fire M:N. Inițiativa Google este legată de deschiderea unui API dezvoltat în spatele ușilor închise pentru kernelul Linux, care asigură funcționarea subsistemului de multiprocesare implementat în spațiul utilizatorului, care folosește modelul de fire M:N. Subsistemul este utilizat de Google pentru a asigura funcționarea serviciilor care necesită întârzieri minime. Planificarea și gestionarea distribuției firelor se realizează integral în spațiul utilizatorului, ceea ce permite reducerea semnificativă a numărului de operații de comutare a contextului prin minimizarea apelurilor de sistem.
Pentru a asigura funcționarea acestui subsistem la nivelul kernelului Linux, a fost implementat API-ul SwitchTo, care oferă trei operații de bază — wait, resume și swap (comutare). Pentru a fi inclus în kernel, s-a propus codul unei noi operații FUTEX_SWAP, care completează , și oferă baza pentru crearea bibliotecilor multiprocesare în spațiul utilizatorului. FUTEX_SWAP poate fi, de asemenea, utilizat pentru a transmite mesaje între sarcini, similar cu RPC. De exemplu, în prezent, pentru a transmite un mesaj între sarcini, este necesar să se efectueze cel puțin patru apeluri FUTEX_WAIT și FUTEX_WAKE; utilizarea FUTEX_SWAP va permite o singură operație, care va fi efectuată de 5-10 ori mai repede.
În prezent, în practică, sunt utilizate în principal modelele de fire 1:1 și N:1. Modelul 1:1 este utilizat în (fire POSIX) și , și implică o asociere directă a unui fir în spațiul utilizatorului cu un fir (unitate de planificare) la nivelul kernelului. Modelul N:1 este implementat în , mutând desfășurarea firelor în spațiul utilizatorului și permițând N fire în spațiul utilizatorului să fie legate de un singur fir în kernel, fără ca kernelul să aibă informații despre firele utilizatorului.
Principalul dezavantaj al modelului 1:1 este costul mare asociat comutării contextului între nucleu și spațiul utilizatorului. Modelul N:1 rezolvă această problemă, dar creează una nouă: deoarece fluxul din nucleu este o unitate indivizibilă de planificare a execuției, fluxurile utilizatorului legate de un singur flux din nucleul sistemului de operare nu pot fi scalate pe nuclee CPU și sunt blocate pe un singur nucleu CPU.
Modelul M:N este hibrid și elimină toate dezavantajele menționate anterior prin asocierea N fluxuri din spațiul utilizatorului cu M fluxuri din nucleul OS, ceea ce permite atât reducerea costurilor de comutare a contextului, cât și asigurarea scalabilității pe nucleele CPU. Prețul acestei opțiuni este o complexitate mai mare în implementarea planificatorului de fluxuri în spațiul utilizatorului și necesitatea unor mecanisme de sincronizare a acțiunilor cu planificatorul nucleului.
Sursa: opennet.ro
