On Fri, 13 Feb 2004 21:17:22 +0100, "Tito"
Post by TitoPost by CésarRespecto al problema de Linux, estoy casi seguro de que éste SO
sólo permite tener un hilo de un proceso ejecutándose a la vez, ya
que todos los hilos que crea un proceso forman parte del mismo.
Por eso la biblioteca de hilos de Posix se implementa como "green threads"
(me parece que se llama así a esto, corregidme). Es el código del propio
hilo el que se encarga de la planificación de "hilos verdes". Lo que pienso
ahora es que, con este sistema, el código de estos hilos no deberían usar
llamadas que provoquen un bloqueo, ¿no?, porque entonces no sé cómo haría el
hilo para hacer la planificación... No sé si me explico...
Post by CésarNo ocurre así con otras versiones de Unix que mapean cada hilo en un
proceso distinto.
Solaris, por ejemplo.
Bien no estoy muy puesto en Linux, pero esto es lo que tengo entendido
respecto a su soporte de threads y en especial SMP:
En Linux existen dos tipos de threads: threads de espacio de usuario y
treads de espacio de kernel.
El soporte para threads de espacio de usuario, se realiza a traves de
una libreria de usuario que proporciona mecanismos de multitarea
cooperativa. Estas funciones provocan el cambio de ejecucion entre
las distintas tareas definidas dentro del proceso. Por ejemplo, un
thread puede enviar una señal provocando que un planificador provoque
un cambio de tarea, o un timer puede provocar que el planificador de
la ejecucion a un thread en algun otro momento. El cambio de tarea se
produce a traves de una simple manipulacion de pila, por que solo se
realiza dentro de determinados contextos. con lo que el costo de
conmutacion de tarea es bajo.
El kernel no tiene conocimiento de estos threads. Si un thread no cede
el control, no se producira la conmutacion de tarea. Ademas si un
thread de usuario se bloquea en la espera de algun recurso, el bloqueo
se produce para todos los threads dentro del proceso. Tambien debido a
esto, estos threads no correran de forma simultanea en mas de una CPU,
aunque haya mas de una CPU disponible.
Creo recordar, que los pthreads en Linux se implementan con threads de
usuario.
Los threads de espacio de kernel de linux, se parecen mas a los
threads de NT o Solaris, proporcionan multi-tarea pre-emptive y se
aprovechan de arquitecturas multi-procesador. Sin embargo en Linux se
opto por una solucion un tanto extraña. El cambio consistio en
proporcionar una version de fork en la que se duplicaba el proceso y
se podia especificar que recursos se compartian con el proceso padre,
dando lugar a un modelo sencillo de implementar, pero lento y menos
flexible. Por ejemplo, la conmutacion a un thread de espacio de kernel
(un proceso mas en linux), implica un cambio del contexto entero de
proceso. De la misma forma. un thread de este tipo no tiene capacidad
para definir la afinidad de procesador u otras cualidades que se
observan en sistemas donde los threads poseen su propia identidad.
El planificador de Linux se encarga de repartir el trabajo procurando
evitar cambios de CPU que provoquen demasiada carga.
Linux ha introducido soporte para SMP en el kernel 2.0. El problema es
que para evitar incosistencias en sus estructuras internas, un sistema
central de bloqueo impedia a distintos procesos entrar en modo kernel
a la vez, y esto aunque las tareas fuesen compatibles (un proceso
espere una lectura de disco y otro por ejemplo envie datos a la
pantalla o a la red). Asi que el kernel secuencia los accesos de los
procesos al entrar en el, independientemente de lo que hagan. Algunos
defensores a ultranza de Linux mantenian que esto no era tan
importante por que el bus PCI ya estaba suficientemente ocupado ;-),
pero el caso es que solo se aprovechaban los multiples procesadores si
un programa estaba haciendo calculo intensivo sin acceder a nada mas.
El problema se ha resuelto en parte a partir de la 2.1 del kernel, se
mejoro el mecanismo de bloqueo, y aqui las interrupciones, manejadores
de señales, y algunas rutinas de I/O tienen sus propios bloqueos. Pero
esto tiene todavia que mejorar mucho, y es culpa sobre todo de una
arquitectura monolitica e insuficiente granularidad.
En NT la unidad de ejecucion es el thread. Todos los threads son
objetos gestionables por el kernel, proporcionado multitarea
pre-emptive con lo que se evita que un thread acapare el uso del
procesador. Ya que NT soporta SMP, el planificador repartira los
threads entre los procesadores disponibles (aunque un thread puede
definir una afinidad de procesador, la cual especifica en que
procesador ejecutar el thread).
Un proceso se compone de uno o varios threads y una serie de recursos
asignados y compartidos por los threads del mismo proceso. Un thread
puede definir atributos de forma independiente al proceso y a otros
threads.
En NT el concepto de threads de usuario de Linux se implementa a
traves de fibras. Y al igual que en Solaris, existen APIs que permite
mapear fibras a theads.
En Solaris, se combinan threads de usuario y threads de kernel. El
sistema mapea un grupo de threads de usuario en threads del kernel.
Una comparativa entre este sistema y el de NT se puede encontrar en:
http://www.usenix.org/publications/library/proceedings/usenix-nt98/full_papers/zabatta/zabatta_html/zabatta.html
Aqui sin embargo no se tiene en cuenta librerias que bajo NT hace
exactamente lo mismo: mapear fibras en threads.
Un saludo,
Martin