elMeu blog

Implementant llibreries de threads, n:n versus m:n

Gràcies a les lecutres que aquest quadrimestre fem a les classes de EDSO a la facultat d'informatica de Barcelona, estic tenin la oportunitat de culturitzar-me una miqueta en algunes de les diferents implementacions de threads que s'han fet els darrers anys.

Els darrers anys aquest ha sigut un camp d'investigació força actiu entre els diferents investigadors de moltes facultats i grans empreses, en certa mesura això és aixins per els canvis que s'estan o s'han produït ja en la forma d'accedir a les aplicacions, en la potencia de processament dels ordinadors i en relació als dos en la demanda creixen per augmentar la concurrència d'accés en determinats punts del sistema, clar exemple el tenim en les modificacions que hi han hagut entre apache 1.3 i apache 2.0.

El kernel de GNU/Linux ha sigut i serà sens dubte un laboratori ideal per aquest tipus de investigacions, com també ho ha sigut la propia maquina virtual de Java.

En un dels papers recents que varem discutir reactive threads, es van posar sobre la taula algunes preguntes interessants, entre elles les diferencies entre els models n:n i m:n. I clar en certa mesura cercar-ne les possibles deficiències o avantages d'un versos l'altre.

Només com a recordatori comentar que una estructura de cardinalitat n:n, executa n trheads d'usauri per n threads de kernel, en canvi m:n executa m threads d'usuari per n threads de kernel, aquesta sutil diferència té sotarrada una discusió historicament enfrontada.

Recordo que en un altre paper, dels primers que varem llegir, que parlava també d'una altre implementacio de threads anomenada Capriccio threads hem va portar a llegir de forma desinteressada l'evolució dels ultims anys de les implementacions tradicionals en el Kernel de Gnu/Linux.

Curiosament, i aquesta és la part que voldria destacar del post, hem vaig trobar amb una especie de buit considerable entre els pensaments dels investigadors de les implementacions fetes en universitats , com ara les dues esmentades, i les implementades per la gent del Kernel de GNU/Linux.

Només a nota de tall històric començar que GNU/Linux va començar amb una primitiva aproximació de Threads anomenada Linux Threads, que va aguantar fins les darreries del kernel 2.4, aquesta era una implementacio que no suportava l'estandar POSIX i tenia una mala relació "tecnologicament parlant" amb el kernel. Aquesta implementacio si no recordo malament en certa mesura ja era N:N, pero tenia uns resultats pessims degut a la quasi inexistent concepció del procés lleuger en el kernel de Linux. Més endavant i en la versió 2.5 Ingo Molnar va implementar el que avui és NPTL - Native Posix Linux Threads - i que seguia amb la ja coneguda cardinalitat n:n. Aquesta nova implementació suposava un avenç gràcies a la posta a punt en el kernel de GNU/Linux del concepte de procés lleuger - ampliació de clone i altres coses interessants - i per tant millorava substancialment no només la capacitat de crear threads de forma llegure si no que començava a implementar de forma verídica tot l'standard POSIX.

Això passava ara farà poc més de 4 anys, en aquella época les investigacions sobre implementacions de cardinalitat m:n ja eren no només un fet si no una realitat, en canvi aquesta va ser descartada de facto pel grup de desenvolupadors de NPLT, i de la mateixa manera no crec que hi hagi hagut una reflexió al voltant d'això aquests ultims anys. La pregunta doncs seria basicament, perquè ?

Be, tot i ser una húmil suposició crec que el problema es ara mateix que el buit que comentava abans és totalment insalvable, a no se que es produeixin canvis significativament importants en l'estructura monolítica del kernel de linux. En certa mesura una bona implementació de trheads amb cardinalitat m:n necessita de certa informació del sistema opreatiu - diguis feedback - per poder realitzar acuradament el seu scheduling intern, i això vol dir delegar responsabilitats sobre una entitat que està fora del sistema operatiu. Tot i que està demostrat que amb les modificacions pertinents - llegiu benchmarks del tema - al sistema operatiu les capacitats o potencialitats de una implementació m:n són millors, aquesta en certa mesura trenca de forma massa radical en la visió de la implementació actual del kernel de linux.