1

Programacin Concurrente
Introduccin al concepto de hilos
Por Jos M Toribio Vicente
Universidad de Valladolid
editedbyjsm
Barcelona, Espaa. 7/ 11/ 2000
Comunicaciones entre procesos
Las aplicaciones informticas pueden ser de muchos
tipos, desde procesadores de texto hasta procesadores
de transacciones (bases de datos), simuladores de
clculo intensivo, etc.
Las aplicaciones estn formadas de uno o ms
programas. Los programas constan de cdigo para la
computadora donde se ejecutarn. El cdigo es
generalmente ejecutado de forma secuencial.
Normalmente, un "programa hilado" (threaded
program, programaconstruido mediante hilos) tiene el
potencial de incrementar el rendimiento total de la
aplicacin en cuanto a productividad y tiempo de
respuesta mediante ejecucin de cdigo asncrono y
paralelo.
La ejecucin de cdigo paralelo se realiza mediante la
ejecucin de dos o ms partes de un programaen dos o
ms procesadores en un instante dado. La ejecucin
asncronase puede realizar conmutando laejecucin del
segmento de cdigo actual que se bloquea por alguna
razn, a otro segmento. Los hilos permiten al
programador emplear estas caractersticas y muchas
otras.
Otros beneficios de los hilos estn relacionados con los
recursos compartidos y el escaso tiempo empleado en su
creacin, terminacin y cambio de contexto. Todo esto
contribuye aincrementar el rendimiento de laaplicacin
as como conservar los recursos del sistema. Cuando un
programa se activa en el sistema, es decir est en
ejecucin o es candidato paralaejecucin, se le conoce
como un proceso. Cuando un proceso se encuentra
activo, se le asignan una serie de recursos del sistema
operativo paragestionarle, entre ellos unaentradaen la
tabla de procesos, un rea de usuario, un contexto de
registros nico, memoriavirtual, etc. Lamayorade los
sistemas operativos slo soportan procesos. Los
procesos pueden ser vistos como una entidad "hilo
simple", es decir, ejecutan slo un flujo de instrucciones
de unaformasecuencial. Los procesos son planificados
para ejecucin una y otra vez hasta que finalizan, es
decir, el programa termina su tarea. Cuando es
planificado, un proceso se ejecutar en un procesador
durante un intervalo de tiempo llamado quantumde
tiempo. Un quantum es simplemente la cantidad de
tiempo que el proceso tiene permitido parasu ejecucin
antes de que el sistemaoperativo compruebe si existe un
proceso de mayor prioridad listo paralaejecucin. Un
nuevo proceso es planificado paraejecucin en lugar del
proceso actual cuando:
1. El quantum de tiempo del proceso actual
finaliza.
2. El proceso actual se bloquea, duerme, finaliza,
o es desalojado.
Siendo un hilo simple, unaaplicacin puede ejecutarse
slo en un procesador en un instante dado y slo puede
ejecutarse de forma secuencial. Una forma de
incrementar la velocidad de ejecucin de un programa
secuencial sera dividir el trabajo entre mltiples
procesadores. Es aqu donde los hilos resultan tiles.
En los sistemas operativos tradicionales, cada proceso
tiene un espacio de direcciones y un nico hilo de
control (contador de programa). Es lo que normalmente
se entiende por proceso. Sin embargo, existen ocasiones
en las que seraconveniente que dos procesos trabajasen
de forma concurrente pero con una serie de datos
comunes. Este problema es difcil de resolver
normalmente, yaque los procesos son independientes y
la comunicacin de los datos debe realizarse mediante
algn mecanismo de comunicacin entre procesos
(IPC), como pueden ser: semforos, memoria
compartida, paso de mensajes, etc. Pero parece claro
que se introduce unaciertacomplejidad en laresolucin
de este tipo de problemas.
Unasolucin que parece razonable consistiraen que los
"procesos" compartiesen el espacio de direcciones (la
memoria), de esta forma no sera necesario su
intercomunicacin, ya que todos tendran acceso a la
mismazonade memoria. Se plantean sin embargo otros
problemas, como es el acceso concurrente aunamisma
posicin de memoria, evitando los problemas de
inconsistenciade datos.
El significado exacto del trmino thread no est
acordado. Uno de los usos ms habituales denota a
procesos ligeros (con flujo de control secuencial) que
comparten un espacio de direcciones y algunos otros
recursos, y para los cuales el tiempo empleado en el
cambio de contexto es mucho menor que el empleado
en los procesospesados(procesos soportados por el kernel
del sistemaoperativo).
Los hilos son flujos de control independientes dentro de
un mismo proceso que comparten datos globales
(variables globales, ficheros, etc.), pero poseen unapila,
variables locales y contador de programa, propios. Se les
suele llamar "procesos de peso ligero" porque su
contexto es menor que el contexto de un proceso. Por
lo tanto, los cambios de contexto entre hilos son menos
costosos que los cambios de contexto entre procesos.
Adems, los hilos son un modelo adecuado para
explotar el paralelismo en un entorno multiprocesador
de memoriacompartida. Lagestin de procesos es uno
de los aspectos claves en el diseo de un sistema
operativo. De la optimizacin de su funcionamiento
depende en gran medidalabuenautilizacin del sistema
y sus recursos.
2
La historia de los hilos
Lanocin de hilo, como flujo de control secuencial, se
remontaal menos, al ao 1965 [OSU96], con el sistema
de tiempo compartido de Berkeley. Slo que en aquel
tiempo no fueron llamados hilos, sino procesos. Los
procesos interactuaban a travs de variables
compartidas, semforos, o mecanismos similares. Max
Smith realiz un prototipo de implementacin de hilos
en Multics alrededor de 1970; usabapilas mltiples en
un proceso pesado simple parasoportar compilaciones
en background.
Sin embargo, el progenitor ms importante de los hilos
fue el lenguaje de programacin PL/ I, hacia el ao
1965. El lenguaje, segn fue definido por IBM,
proporcionaba una instruccin del tipo CALL XXX
(A, B) TASK; construccin que bifurcabagenerando un
hilo paraXXX. No se sabe si algn compilador de IBM
implement esta caracterstica, pero fue estudiado
exhaustivamente mientras se estabadiseando Multics;
se comprob que la llamada TASK como estaba
definida no mapeaba en procesos, ya que no exista
proteccin entre los hilos de control. Entonces Multics
tom unadireccin diferente, y lacaractersticaTASK
fue eliminadade PL/ I por IBM.
Despus vino UNIX, a principios de 1970. La nocin
UNIX de 'proceso' consista en un hilo de control
secuencial ms un espacio de direcciones virtuales (esta
nocin deriv directamente del proceso de diseo de
Multics). As pues 'procesos', en el sentido de UNIX,
son "mquinas pesadas". Yaque no pueden compartir
memoria (cada proceso tiene su propio espacio de
direcciones), interactuan a travs de tuberas, seales,
etc. La memoria compartida fue aadida a UNIX
mucho ms tarde. Despus de algn tiempo, los
usuarios de UNIX comenzaron a echar en falta los
viejos procesos que podan compartir memoria. Esto
dio lugar ala"invencin" de los hilos: procesos al "viejo
estilo" que compartan el espacio de direcciones de un
simple proceso UNIX. Se les llam, entonces, procesos
ligeros en contraste con los procesos pesados UNIX.
Esta distincin se remonta a finales de los 70's y
principios de los 80's, cuando comenzaron los
desarrollos de los primeros microkernels: Thoth
(precursor del V-Kernel y QNX), Amoeba, Chorus, la
familia RIG-Accent-Mach, etc.
En relacin con los paquetes de hilos, C Threads fue
una de las implementaciones iniciales de hilos, nacida
como unaextensin del lenguaje C basadaen corrutinas.
Unaimplementacin sencillafue empleadapor Cooper
[COO88] como herramienta de enseanza. Esta
implementacin original no gestionabaseales por hilo,
y slo soportabaplanificacin no preemptiva.
El primer sistemaoperativo comercial que implement
hilos fue Mach. Cooper construy unaimplementacin
de C Threads basadaen los hilos Mach que soportaba
planificacin preemptiva. Tambin existe una
implementacin anterior, realizadaen Brown University
[DOE87], de una biblioteca de hilos con planificacin
preemptiva, soporte de diversas arquitecturas (incluso
multiprocesadores) y gestin de seales asncronas.
Posteriormente, algunos sistemas operativos
comerciales, como LynxOS o SunOS, implementaron
alguno de los diversos borradores del estndar POSIX
Threads, empleando un mtodo mixto a dos niveles,
basado en una biblioteca de nivel usuario y soporte
kernel de hilos. Otros sistemas operativos, como
Chorus implementaron la mayor parte de la
funcionalidad en el kernel, debido a sus requisitos de
diseo.
Caractersticas de las implementaciones
Se pueden distinguir dos tipos de implementaciones de
los hilos: hilos anivel deusuarioy los hilos anivel dekernel.
Un hilo anivel de usuario mantiene todo su estado en el
espacio de usuario. Como consecuenciade ello, el hilo
no utilizarecursos del kernel parasu gestin, y se puede
conmutar entre hilos sin cambiar el espacio de
direcciones. Como desventaja, los hilos a nivel de
usuario no se pueden ejecutar mientras el kernel est
ocupado, por ejemplo, con paginacin o E/ S, ya que
esto necesitaraalgn conocimiento y participacin por
parte del kernel.
Es posible combinar ambos mtodos, como se hace en
SunOS 5.x (Solaris 2.x). Aqu, uno o ms procesos
ligeros (light weight processes - LWPs) se ejecutan en
multitarea mediante uno o ms hilos de nivel usuario,
que son implementados usando libreras en el espacio de
usuario.
Algunas razones que caracterizan las implementaciones
de hilos, y que determinan el uso que puede tener un
paquete de hilos, son:
El nmero de recursos del kernel que
necesitarun hilo. Esto limitarel nmero de
hilos que pueden iniciarse paraunaproceso.
En qu momento el proceso entero ser
suspendido. Por ejemplo, si algn hilo genera
una falta de pgina, entonces otro hilo del
proceso puede ser ejecutado o no.
La conmutacin entre hilos requiere una
llamada al sistema (como en la SPARC), o
bien el cambio de contexto entre hilos se
puede realizar completamente a nivel de
usuario.
El nmero de seales gestionadas, si las
seales pueden ser enmascaradas
individualmente por cadahilo o no, y si existe
unaseal de tipo broadcast.
El nmero de pilas gestionadas, y si las pilas
crecern y decrecern dinmicamente en base
acadahilo.
Algunos nuevos sistemas (QNX y Plan 9, por ejemplo)
consideran que los hilos "resuelven el sntoma, pero no
el problema". En estos sistemas se consideraque en vez
de usar hilos, yaque el tiempo de cambio de contexto
del SO es demasiado lento, unamejor aproximacin, es
mejorar el SO en s.
Parece irnico, que ahoraque los SO paraordenadores
de sobremesaincluyen multitareaen modo protegido, el
modelo de programacin de modaconsiste en mltiples
hilos ejecutndose en un espacio de direcciones comn,
haciendo el proceso de depuracin ms difcil, e incluso
haciendo ms difcil lageneracin de cdigo fiable.
3
Con laventajade tener un rpido cambio de contexto, y
existiendo servicios del SO, como lareservaexplcitade
memoria compartida entre un equipo de procesos
cooperando, se puede crear un entornodehilos, sin tener
los problemas que se estableceran en un espacio de
memoriatotalmente compartida.
Concepto de hilo
A continuacin se intentarexplicar el concepto de hilo
mediante un ejemplo. Imaginemos un servidor de
archivos que ocasionalmente debe bloquearse esperando
acceder al disco. Si el servidor tuviera varios hilos de
control, se podra ejecutar un segundo hilo de control
mientras el primero estsuspendido. Esto provocaraun
mejor rendimiento y utilizacin de los recursos. Si se
crean dos procesos servidores independientes, ambos
deberan compartir el buffer de cach, para lo cual
deberan tener un espacio de direcciones comn, lo cual
complicasu diseo. Normalmente se necesitaun nuevo
mecanismo que generalmente no se encuentra en los
sistemas operativos, aunque no existe razn paraesto.
Figura3-1 Tres procesos cadauno con un hilo.
Supongamos tres procesos independientes, cada uno
con su propio contador de programa, su propiapila, su
propio conjunto de registros y su propio espacio de
direcciones. Los procesos no tienen ninguna relacin
entre s, excepto que pueden comunicarse mediante
primitivas del sistema para comunicacin entre
procesos: semforos, paso de mensaje, monitores, etc.
Figura3-2 Un proceso con tres hilos.
Supongamos otramquina, con un slo proceso, pero
dicho proceso tiene varios hilos de control, que suelen
llamarse procesos ligeros o simplemente hilos (threads).
Los hilos son como miniprocesos, yaque cadahilo se
ejecuta de forma estrictamente secuencial, tiene su
propio contador de programay su propiapila. Los hilos
comparten laCPU al igual que lo hacen los procesos en
un sistema de tiempo compartido. Slo en un sistema
multiprocesador se pueden ejecutar realmente en
paralelo. Los hilos pueden crear, igualmente, hilos hijos,
y se pueden bloquear esperando lafinalizacin de una
llamada al sistema. Mientras un hilo se encuentra
bloqueado, se puede ejecutar otro hilo del mismo
proceso, exactamente igual que ocurre cuando un
proceso se bloquea y se ejecuta otro proceso en la
misma mquina. La analoga "hilo es a proceso, como
proceso es amquina" es vlidaen muchos sentidos.
Sin embargo los hilos de un mismo proceso no son tan
independientes como los procesos distintos. Todos los
hilos de un proceso comparten el mismo espacio de
direcciones, con lo cual comparten las mismas variables
globales (las variables locales no son compartidas, ya
que se almacenan en lapila, y cadahilo tiene su propia
pila independiente). Como cada hilo tiene acceso a
cualquier direccin virtual, un hilo puede leer, escribir o
limpiar la pila de otro hilo de su mismo proceso. No
existe proteccin entre los hilos, ya que es muy difcil
proporcionarlay no debe ser necesaria.
Normalmente los procesos, que pueden ser de distintos
usuarios, pueden ser hostiles entre s. En cambio en un
sistema multihilo, un proceso pertenece a un nico
usuario, y puede haber creado varios hilos para que
cooperen entre s.
Los hilos, adems de compartir el espacio de
direcciones, comparten el conjunto de ficheros abiertos,
procesos hijos, relojes, seales, etc. As pues, los hilos
resultan tiles cuando se necesite cooperacin activay
cercanaen laresolucin de un mismo problema.
Elementos de un Hilo Elementos de un Proceso
Contador deprograma espacio dedirecciones
Pila variables globales
Registros descriptores dearchivos
hilos hijos procesos hijos
Estado seales
semforos
relojes
informacin contable
Todos los hilos comparten el mismo espacio de
direcciones, y as comparten tambin las mismas
variables globales. Mientras que los procesos pueden ser
de distintos usuarios y competir por recursos entre si,
los hilos de un mismo proceso de usuario cooperan
entre si, sin luchar entre s.
Al igual que los procesos tradicionales, los hilos pueden
estar en alguno de los siguientes estados:
Enejecucin(Running): cuando el hilo posee laCPU y se
encuentraactivo.
Bloqueado (Suspend): cuando el hilo se encuentra
esperando algn evento o alaesperade que otro libere
el bloqueo por el que se encuentradetenido.
Listoopreparado(Ready): cuando el hilo est preparado
para su ejecucin, y se encuentra a la espera de ser
elegido por el planificador.
Terminado(Finished): cuando el hilo ha finalizado, pero
todavano hasido recogido por el hilo padre, aunque
no puede ser planificado nuncams.
Adems, en algunas ocasiones (segn el diseo) un hilo
puede ser independizado (no tiene relacin de
parentesco con ningn otro) en conjuncin con
cualquiera de los estados anteriores. Cuando un hilo
independizado finaliza o cuando un hilo finalizado es
independizado, cualquier memoria asociada con l es
liberaday el hilo no puede volver aser referenciado.
Un proceso puede tener uno o ms hilos. Los hilos son
un mecanismo que permite mejorar el rendimiento de
los sistemas operativos tratando de reducir lasobrecarga
producida por el cambio de contexto entre procesos.
Los hilos de un mismo proceso comparten los recursos
(memoria, archivos, etc.), y son la unidad de
planificacin. As, un proceso ser un objeto esttico
4
que posee un conjunto de recursos para una serie de
hilos, que son los objetos dinmicos planificables.
Los hilos siempre pertenecen aun proceso, y no tienen
existenciapropiaindependiente. Cadahilo tiene un flujo
de control, unapilay un estado propio. Yaque todos
los recursos, a excepcin de la CPU, son gestionados
por el proceso, la comunicacin entre hilos de un
proceso es mucho ms rpiday eficiente al compartir el
mismo espacio de direcciones. Cuando se produce un
cambio de contexto entre hilos de distintos procesos, se
produce un cambio de contexto completo.
La implementacin de hilos en un sistema operativo
convierte a ste en mucho ms rpido, pero surgen
nuevos problemas de caraal programador, yaque varios
hilos de un mismo proceso pueden acceder aunamisma
variable compartida, lo cual puede ocasionar
inconsistencia en su valor. Sin embargo, a veces, la
utilizacin de los hilos simplifica incluso la tarea del
programador, dependiendo del tipo de aplicacin.
El modelo de programacin de hilos permite ignorar los
detalles de la arquitectura, como el nmero de
procesadores, para concentrarse en el algoritmo
adecuado que exprese la concurrencia. Es pues un
modelo adecuado paralaprogramacin concurrente. La
utilizacin de la concurrencia en un lenguaje de
programacin requiere una cierta disciplina de
programacin junto alautilizacin de nuevas tcnicas.
Los componentes concurrentes de un programapueden
ejecutarse de formaparalelaen un multiprocesador.
Los hilos en un entorno multihilo tienen las siguientes
caractersticas que pueden hacerles deseables en muchas
aplicaciones que requieren multitarea:
Necesitan pocamemoria.
Tienen un bajo coste de creacin.
Tienen un bajo coste de sincronizacin.
Comparten el mismo espacio de direcciones.
Pueden progresar independientemente unos de otros.
Aplicaciones de los hilos
Algunos programas presentan unaestructuraque puede
hacerles especialmente adecuados para entornos
multihilo. Normalmente estos casos involucran
operaciones que pueden ser solapadas. Lautilizacin de
mltiples hilos, puede conseguir un grado de
paralelismo que incremente el rendimiento de un
programa, e incluso hacer ms fcil la escritura de su
cdigo. Algunos ejemplos son:
Utilizacin de los hilos paraexpresar algoritmos
inherentemente paralelos. Se pueden obtener
aumentos de rendimiento debido al hecho de
que los hilos funcionan muy bien en sistemas
multiprocesadores. Los hilos permiten
expresar el paralelismo de alto nivel atravs
de un lenguaje de programacin.
Utilizacin de los hilos parasolapar operaciones
deE/ S lentas con otras operaciones en un
programa. Esto permite obtener un aumento
del rendimiento, permitiendo bloquear a un
simple hilo que esperaaque se complete una
operacin de E/ S, mientras otros hilos del
proceso continan su ejecucin, evitando el
bloqueo entero del proceso.
Utilizacin de los hilos para solapar llamadas
RPC salientes. Se obtiene una ganancia en el
rendimiento permitiendo que un cliente
pueda acceder a varios servidores al mismo
tiempo en lugar de acceder aun servidor cada
vez. Esto puede ser interesante para
servidores especializados en los que los
clientes pueden dividir una llamada RPC
compleja en varias llamadas RPC
concurrentes y ms simples.
Utilizacin de los hiloseninterfacesdeusuario. Se
pueden obtener aumentos de rendimiento
empleando un hilo para interactuar con un
usuario, mientras se pasan las peticiones a
otros hilos parasu ejecucin.
Utilizacin de los hilos en servidores. Los
servidores pueden utilizar las ventajas del
multihilo, creando un hilo gestor diferente
paracadapeticin entrante de un cliente.
Utilizacin de los hilos en procesos pipeline: Se
puede implementar cadaetapade unatubera
o pipeline mediante un hilo separado dentro
del mismo proceso.
Utilizacin de los hilos en el diseodeun kenel
multihilo de sistemaoperativo distribuido que
distribuyadiferentes tareas entre los hilos.
Utilizacin de los hilosparaexplotar lapotencia
delosmultiprocesadores de memoriacompartida
(sistemas fuertemente acoplados).
Utilizacin de los hiloscomosoportedeaplicaciones
de tiempo real acelerando los tiempos de
respuestaparalos eventos asncronos atravs
de lagestin de seales.
Algunas de estas tcnicas pueden ser implementadas
usando mltiples procesos. Los hilos son sin embargo
ms interesantes como solucin porque:
Los procesos tienen un alto coste de creacin.
Los procesos requieren ms memoria.
Los procesos tienen un alto coste de
sincronizacin.
Compartir memoria entre procesos es ms
complicado, aunque compartir memoriaentre
hilos tiene sus problemas.
Los hilos se crearon para permitir combinar el
paralelismo con laejecucin secuencial y el bloqueo de
llamadas al sistema. Las llamadas al sistemacon bloqueo
facilitan la programacin, y el paralelismo obtenido
mejorael rendimiento.
Ejemplo de servidor de archivos
Consideremos el siguiente ejemplo de un servidor de
archivos, en distintas implementaciones:
1) Servidor convarioshilos:
- El hilo servidor, lee las peticiones de trabajo del buzn
del sistema.
- Examina la solicitud, y selecciona un hilo trabajador
inactivo (bloqueado), al cual envalasolicitud mediante
algn tipo de mensaje. Despus el hilo servidor
despierta al hilo trabajador dormido (por ejemplo,
mediante un SIGNAL en el semforo donde duerme).
- Cuando el hilo trabajador despierta, consultalacache
del bloque de memoriacompartidaentre todos los hilos,
paraverificar que puede dar servicio alasolicitud. Si no,
5
enva una solicitud al disco para obtener el bloque de
disco correspondiente (si se tratade unaoperacin de
lectura), y se duerme alaespera. Se llamaal planificador,
y se inicializaotro hilo, que podraser el servidor para
pedir ms trabajo, o bien otro trabajador listo para
realizar un trabajo. Pero veamos como se implementara
el servidor de archivos sin hilos.
2) Servidor con un nico proceso (nico hilo), en el cual el
proceso servidor realiza todo el tratamiento
cclicamente:
- obtener unasolicitud
- examinar el tipo de solicitud
- servir lasolicitud, y volver al principio.
Mientras el proceso esperaal disco, estinactivo y no
procesa otras solicitudes. Si el servidor de archivos se
ejecuta en una mquina dedicada, como suele ser
habitual, la CPU estar inactiva, mientras se espera al
disco, produciendo un menor nmero de solicitudes/ sg.
servidas. As pues, los hilos aumentan el rendimiento de
unaformaimportante, y sin embargo cadauno de ellos
tambin se ejecutade formasecuencial.
3) Servidor comomquinadeestadosfinitos:
- obtener unasolicitud
- examinar el tipo de solicitud
- Si se encuentraen lacach, perfecto, sino se envaun
mensaje al disco, y en vez de bloquearse, se registrael
estado de lasolicitud actual en unatabla
- Despus se consultalatablay se obtiene el siguiente
mensaje, que puede ser una solicitud de un nuevo
trabajo, o una respuesta del disco con respecto a una
operacin pendiente anterior.
- Si es un nuevo trabajo, se comienzasu resolucin. Y si
es una respuesta del disco, se localiza la informacin
necesariaen latablay se procesalarespuesta.
Como no se puede enviar un mensaje y bloquearse ala
espera, no se puede utilizar RPC, as pues las primitivas
deben ser del tipo sendy receivesin bloqueo.
Sin embargo, en este diseo se pierde el modelo "de
proceso secuencial" que tenamos en los casos
anteriores. Necesitamos guardar el estado y restaurarlo
en latablaparacadamensaje enviado o recibido. En el
fondo lo que estamos realizando es unasimulacin de
varios hilos y sus pilas de una manera complicada. El
funcionamiento es el de unamquinade estados finitos
que obtiene un evento y reaccionasegn el estado en el
que se encuentre.
Los hilos, por tanto, mantienen la idea de procesos
secuenciales que realizan llamadas al sistema con
bloqueo (por ejemplo, RPC), y sin embargo permiten el
paralelismo. Las llamadas al sistema con bloqueo
facilitan la programacin, y el paralelismo mejora el
rendimiento del sistema. En el 2 caso, el servidor de un
nico hilo empleallamadas con bloqueo, pero tiene un
bajo rendimiento al no conseguir el paralelismo. El 3
caso, logra un mejor rendimiento mediante el
paralelismo conseguido por la mquina de estados
finitos, pero empleallamadas sin bloqueo que dificultan
laprogramacin.
Otras aplicaciones de los hilos
Los hilos tambin pueden ser muy tiles en la
implementacin no slo de procesos servidores, sino de
procesos clientes. Por ejemplo, si un cliente quiere copiar
un archivo en varios servidores, puede hacer que un hilo
se comunique con cadaservidor.
Tambin se pueden emplear los hilos en el manejo de
seales, como por ejemplo las interrupciones del teclado:
se puede dedicar un hilo alaesperade seales, en vez de
que stas interrumpan el proceso. Normalmente, el hilo
se bloqueaalaesperade seales, y cuando se produce
unaseal, despiertay laprocesa. Esto puede eliminar la
necesidad de interrupciones anivel de usuario.
Otrarazn de peso que justificalautilizacin de hilos, y
que no tiene relacin con las RPCs o lacomunicacin,
se basa en que muchas tareas son ms fciles de
programar mediante procesos paralelos, yaque tienen una
naturaleza inherentemente paralela. Como ejemplo
encontramos el problema del productor-consumidor.
Este problemaes de naturalezaparalela, yaque de esta
forma es ms fcil su diseo, al margen de que en la
realidad el productor y el consumidor se ejecuten o no
de forma paralela. Adems, dada la necesidad de
compartir un buffer comn, este problema se adapta
perfectamente al caso de los hilos.
Como ltima justificacin, en un sistema
multiprocesador, es posible que los hilos de un mismo
proceso se ejecuten realmente en paralelo, en varias
CPU. Un programa bien diseado y que emplee hilos
funcionar tanto en una CPU con hilos compartidos,
como en un verdadero multiprocesador, lo que hace al
diseo independiente de laimplementacin.
El empleo de los hilos en el desarrollo de aplicaciones
puede tener la recompensa de incrementar el
rendimiento de la aplicacin. Un incremento en el
rendimiento de laaplicacin puede significar unaventaja
competitiva, sin embargo larobustez de laaplicacin y
la portabilidad de lamisma, han de tenerse tambin en
consideracin. Desarrollar aplicaciones robustas basadas
en hilos es posible con un correcto entrenamiento y con
herramientas que ayuden al mantenimiento del
programa. Desarrollar aplicaciones portables ser
posible cuando la industria se cia al nuevo estndar
POSIX 1003.1c.
Organizacin de los hilos de un proceso
Otraformade estudiar las posibilidades de emplear los
hilos es pensar en trminos de modelos de
programacin. La programacin multihilo es
especialmente til en algunos modelos de programacin.
Los hilos se pueden organizar de distintas formas para
que cooperen entre s en laresolucin de un problema.
Existen unaserie de modelos tpicos de organizacin de
los hilos de un proceso. Veamos cadamodelo aplicado
al ejemplo del servidor de archivos:
Modeloservidor/ trabajador: En este modelo un
hilo funciona como supervisor asignando
tareas a los hilos trabajadores. Despus de
que el trabajador ha finalizado su tarea, lo
indicaal supervisor o es el supervisor quien lo
compruebapor s mismo, paradespus recibir
unanuevatarea. Es el modelo empleado en el
primer ejemplo del servidor de archivos. Un
hilo servidor que obtiene las solicitudes y las
redirige a los hilos trabajadores, que realizan
el servicio.
6
Modelodecola detrabajo: Este modelo es una
variante del modelo servidor/ trabajador. En
este modelo las tareas son colocadas por el
servidor o supervisor en una cola que es
accedida por los trabajadores hasta que se
vaca.
Modelo de equipo: En este modelo mltiples
hilos trabajan juntos en una tarea simple.
Cadahilo realizaunaparte de latarea, como
unacasaen laque cadapintor pintaunaparte
de la misma. Todos los hilos son iguales, y
cada uno obtiene y procesa sus propias
solicitudes. No existe un hilo servidor. Se
puede asociar unacolade trabajo acadatipo
de solicitud, de tal forma que existan tantas
categoras de hilos como tipos de solicitud.
Un hilo slo dar servicio a un tipo de
solicitud, teniendo preferencia las solicitudes
en esperaen lacolacorrespondiente frente las
solicitudes del buzn del sistema.
Modelodetubera oentubamientoopipelining: En
este modelo se emplea el esquema de una
cadena de montaje, con cada hilo realizando
un determinado paso en latarea. Tan pronto
como un hilo termina un paso de la tarea,
otro hilo trabaja en ella. Cuando un hilo
terminaun paso, puede empezar atrabajar en
el mismo paso de otratarea. En este modelo
los hilos trabajan de forma encadenada. El
primer hilo genera ciertos datos, y los
transfiere al siguiente hilo que realizarcierto
procesamiento sobre los mismos, y generar
nuevos datos de salida. El proceso se puede
repetir con ms hilos encadenados. Los datos
pasan de un hilo aotro, y en cadapaso sufren
cierto procesamiento. Estasolucin puede ser
apropiadaen algunos problemas como el del
productor-consumidor o en las lneas de
comandos de UNIX, aunque no parece
adecuado para el problema del servidor de
archivos.
Combinacindemodelos: En este caso se emplea
unamezclacon ms de un modelo.
Diseo de un paquete de hilos
Es posible implementar una biblioteca de hilos que
soporte planificacin preemptiva, rpidos cambios de
contexto entre hilos, secciones crticas pequeas, evite el
crecimiento ilimitado de lapila, emplee pocas llamadas
al sistema, y proporcione un interfaz independiente del
lenguaje.
Un paquete de hilos consiste de un conjunto de
primitivas relacionadas con la gestin de los hilos, y
disponibles paraque el programador realice aplicaciones
multihilo. El paquete de hilos tambin se encargarde
gestionar, controlar, crear y destruir los hilos que la
aplicacin multihilo requiere para su ejecucin. Los
paquetes de hilos suelen tener tambin llamadas para
especificar el tipo de algoritmo de planificacin deseado
paralos hilos: round-robin, prioridades, etc., as como
establecer las prioridades en su caso.
Paramaximizar el rendimiento de labibliotecade hilos,
las llamadas al kernel del sistema operativo deben ser
minimizadas. Lasobrecargaasociadacuando se entray
se sale del kernel del sistema hace que las llamadas al
sistemasean operaciones muy costosas. Lamayorade
las llamadas que debe realizar el paquete estarn
relacionadas con lainicializacin de labibliotecay otra
serie de etapas que no sean crticas en tiempo.
Existen dos formas de gestionar los hilos:
a) DiseodeHilosEstticos: El numero de hilos se fijaal
escribir el programao durante lacompilacin. Cadahilo
tiene asociadaun pilafija. Es unaalternativasimple pero
inflexible.
b) Diseo deHilos Dinmicos: Se permite la creacin y
destruccin de hilos durante la ejecucin. En este
modelo un proceso se iniciacon un slo hilo (de manera
implcita), pero puede crear ms hilos posteriormente.
Este suele ser el diseo habitual empleado en los
paquetes de hilos actuales.
Existe una llamada para la creacin de hilos que
determina el programa principal del hilo, para ello se
pasaalallamado un puntero al procedimiento principal,
un tamao para la pila del hilo, y otra serie de
parmetros, como puede ser la prioridad de
planificacin. La llamada devuelve un identificador del
hilo. Lasintaxis abstractade lallamadade creacin de
hilos es id_Hilo CreateThread(puntero_procedimiento,
tamao_pila, Parametros...)
Un hilo puede finalizar su ejecucin por dos razones (al
igual que un proceso): la terminacin natural de su
trabajo o su eliminacin desde el exterior.
Estructura bsica
El estndar POSIX Threads especifica un modelo de
hilos dirigido por prioridades con polticas de
planificacin preemptivas, gestin de seales, y
primitivas paraproporcionar exclusin mutuaas como
espera sincronizada. El diseo de un paquete de hilos
suele estar influenciado por las restricciones impuestas
por el estndar POSIX Threads (si se deseaseguir dicho
estndar, caso habitual) y el tipo de plataformasobre la
que se va a implementar. Normalmente el diseo del
paquete intentareducir al mnimo lacantidad de cdigo
dependiente de la plataforma, y se suele aislar en
7
mdulos concretos, de forma que la biblioteca sea
adaptable anuevas plataformas.
En la mayora de las implementaciones, el interfaz
consiste en una biblioteca C con puntos de entrada
enlazables, de forma que pueda ser compilada para
generar un interfaz de lenguaje independiente. Este es el
caso de laimplementacin Pthreads realizadapor Frank
Mueller como base del proyecto PART (Portable Ada
Run-Time).
Un interfaz permite que los programas empleen los
servicios de la biblioteca independientemente del
lenguaje que empleemos. En el caso del lenguaje C, las
rutinas de la biblioteca son utilizables directamente,
mientras que en otros lenguajes es necesario crear un
interfaz entre el lenguaje y labibliotecade hilos.
En algunos diseos de paquetes de hilos, el cdigo de
las rutinas de la biblioteca se ejecuta normalmente en
modousuario, aunque las secciones crticas se ejecutan en
un modoprotegidookernel delabiblioteca(no confundir con
el modo kernel del sistema), que es un modo especial
que garantiza la exclusin mutua entre hilos. Estas
implementaciones suelen emplear rutinas de la
biblioteca estndar del sistema y algunas llamadas al
kernel del sistema.
Los objetivos de diseo que deben prevalecer son:
Planificacin preemptiva: Polticas de
planificacin como Round-Robin y seales o
eventos asncronos junto con prioridades,
slo pueden ser soportados mediante un
diseo de kernel preemptivo.
Cambios de contexto rpidos: El cambio de
contexto debe ser lanicacausapor lacual el
control es transferido de un hilo a otro, de
forma que se debe intentar reducir la
sobrecargadel cambio de contexto.
Impedir el crecimiento de pila ilimitado: Si se
produce un evento asncrono mientras se
ejecuta un gestor de interrupciones, otro
gestor puede ser introducido en la pila y as
hasta el infinito. Este caso se debe evitar
mediante algunasolucin particular.
Sincronizacin
Como los hilos comparten el espacio de direcciones,
comparten las variables globales. El acceso a dichas
variables se realiza generalmente mediante regiones
crticas, paraevitar que varios hilos tengan acceso alos
mismos datos al mismo tiempo. Por ello es necesario
sincronizar el acceso alos recursos compartidos por los
hilos de un proceso. Laimplementacin de las regiones
crticas es ms sencillautilizando semforos, monitores
u otras construcciones similares.
El estndar POSIX Threads especificaun mtex como
estructurade datos paragarantizar el acceso exclusivo a
datos compartidos, y variables de condicin pararealizar
la sincronizacin entre hilos. Otros mtodos de
sincronizacin tales como semforos contadores pueden
implementarse empleando estas primitivas.
Normalmente los paquetes de hilos implementan las
siguientes tcnicas:
Mtex
Un mtex consiste en unaespecie de semforo binario
con dos estados, cerrado y no cerrado. Un mtex es un
objeto que permite alos hilos asegurar laintegridad de
un recurso compartido al que tienen acceso. Tiene dos
estados: bloqueado y desbloqueado. Sobre un mtex se
pueden realizar las siguientes operaciones:
LOCK: Intentacerrar el mtex. Si el mtex no
estcerrado, se cierra, todo ello en unaaccin
atmica. Si el mtex est cerrado, el hilo se
bloquea. Si dos hilos intentan cerrar el mtex
al mismo tiempo, cosaque slo puede pasar
en un multiprocesador real, uno de ellos lo
consigue y el otro no, bloquendose. La
forma de regular esto depende de la
implementacin.
UNLOCK: Elimina o libera el cierre del
mtex. Si existe uno o ms hilos esperando
por el mtex, se desbloqueaexactamente uno,
y el resto permanece bloqueado alaespera.
TRYLOCK: Intenta cerrar un mtex. Se
devuelve un cdigo indicando el resultado del
intento de bloqueo: OK (se pudo cerrar) o
ERROR (el mtex estabacerrado, pero el hilo
no se bloque alaespera).
Antes de acceder aun recurso compartido un hilo debe
bloquear un mtex. Si el mtex no hasido bloqueado
antes por otro hilo, el bloqueo es realizado. Si el mtex
ha sido bloqueado antes, el hilo es puesto a la espera.
Tan pronto como el mtex es liberado, uno de los hilos
en espera a causa de un bloqueo en el mtex es
seleccionado para que contine su ejecucin,
adquiriendo el bloqueo.
Un ejemplo de utilizacin de un mtex es aqul en el
que un hilo A y otro hilo B estn compartiendo un
recurso tpico, como puede ser unavariable global. El
hilo A bloqueael mtex, con lo que obtiene el acceso a
lavariable. Cuando el hilo B intentabloquear el mtex,
el hilo B es puesto alaesperapuesto que el mtex yaha
sido bloqueado antes. Cuando el hilo A finaliza el
acceso alavariable global, desbloqueael mtex. Cuando
esto suceda, el hilo B continuar la ejecucin
adquiriendo el bloqueo, pudiendo entonces acceder ala
variable.
HiloA: HiloB:
lock(mutex) lock(mutex)
acceso al recurso acceso al recurso
unlock(mutex) unlock(mutex)
Un hilo puede adquirir un mtex no bloqueado. De esta
forma, la exclusin mutua entre hilos del mismo
proceso est garantizada, hasta que el mtex es
desbloqueado permitiendo que otros hilos protejan
secciones crticas con el mismo mtex. Si un hilo intenta
bloquear un mtex que ya est bloqueado, el hilo se
suspende. Si un hilo desbloqueaun mtex y otros hilos
8
estn esperando por el mtex, el hilo en espera con
mayor prioridad obtendrel mtex. Parasimplificar las
implementaciones, normalmente un hilo no puede ser
cancelado cuando tiene cancelacin activada y
controlada, y se suspende debido alaesperadel mtex,
con el fin de garantizar un estado determinista del
mtex en los gestores de limpieza.
Un mtex debe ser bloqueado durante el menor tiempo
posible paraminimizar laespera. Por ejemplo, se debe
proteger el acceso a estructuras de datos compartidas
entre hilos mediante mtex. Pero no se debe bloquear
un mtex, realizar una accin que puede provocar la
suspensin del hilo, y despus desbloquear el mtex,
porque se puede producir la espera durante un largo
periodo mientras se posee el mtex.
Variables de condicin
Unavariable de condicin es un objeto que permite que
los hilos se ejecuten en un secuenciaordenada. Los hilos
pueden esperar aque se cumplaunaciertacondicin, o
pueden indicar a otros hilos que se ha producido una
cierta condicin, liberando uno o ms hilos de la
condicin de espera. Existe un mtex y un predicado
asociados con unavariable de condicin. El predicado
es unavariable especficade laaplicacin comprobada
por los hilos, indicando que algn tipo de condicin est
listao no. El predicado es necesario porque lavariable
de condicin misma es opaca, siendo usado en las
operaciones wait y signal. El mtex de la variable de
condicin asegura que un hilo como mximo est
accediendo al predicado y entrando en un estado de
esperao enviando unaseal basadaen su valor.
Tpicamente, una variable de condicin es empleada
paraindicar cuando un hilo debe comenzar atrabajar en
una tarea. Esto puede ser til para implementar el
modelo de hilos de trabajo en equipo, haciendo que los
hilos trabajadores esperen por unavariable de condicin
usada como un flag para indicar el instante de
comienzo. En el modelo de tubera se puede emplear
una variable de condicin para indicar que la etapa
anterior de unatareahasido completadapor algn hilo.
Un ejemplo de utilizacin de unavariable de condicin
es aquel en el que un hilo A bloqueaun mtex asociado
con unavariable de condicin. Eventualmente el hilo A
adquiere el bloqueo de este mtex, procediendo
entonces aacceder al predicado. Si el predicado indica
un estado deseado, el hilo A procederadesarrollar la
tareaX y desbloquearel mtex. Si no, el hilo A entrar
en un estado de espera, pero laoperacin wait realizar
automticamente el desbloqueo del mtex. El hilo B
bloqueael mtex asociado con lavariable de condicin
despus de haber completado la tarea Y.
Eventualmente, el hilo B adquirir el bloqueo de este
mtex, procediendo entonces aacceder al predicado. El
hilo B pondrel predicado en el estado ready, indicando
con signal que el predicado estlisto y desbloqueando el
mtex. Si el hilo A estabaesperando en lavariable de
condicin, la indicacin signal emitida por el hilo B
provocar que el hilo A contine su ejecucin.
Supongamos lasecuenciaen laque el hilo A slo realiza
la tarea X despus de que el hilo B haya realizado la
tarea Y. El hilo B indica que ha realizado la tarea Y
empleando una variable de condicin accedida por
ambos hilos A y B.
HiloA: HiloB:
lock(mutex) Realizar TareaY
while (!predicado) lock(mutex)
wait(var_condic, mutex) predicado = TRUE
Realizar TareaX signal(var_condic)
unlock(mutex) unlock(mutex)
Para permitir la sincronizacin entre hilos y la
suspensin durante un largo intervalo de tiempo, se
emplean las variables de condicin. Una variable de
condicin est asociada con un mtex y un predicado
basado en datos compartidos. Cuando un hilo necesita
sincronizarse con otro, bloqueael mtex, compruebael
predicado y, si el predicado se evala a falso, se
suspende en la variable de condicin. Cuan el hilo es
reactivado, vuelve aevaluar el predicado y as hastaque
el predicado se hace cierto. Laevaluacin nuevamente
del predicado es esencial yaque las reactivaciones en un
multiprocesador y las reactivaciones debidas a eventos
asncronos pueden causar que el hilo contine su
ejecucin mientras el predicado permanece a falso,
debido aque las operaciones no son atmicas.
Cuando un hilo entraen unaesperacondicional con el
mtex asociado bloqueado, el mtex es desbloqueado y
el hilo suspendido en una sola operacin atmica. De
forma similar, el mtex es bloqueado nuevamente
cuando el hilo continuasu ejecucin, de formaatmica.
As pues, el mtex asociado estsiempre en un estado
conocido, incluso cuando las seales interrumpen una
esperacondicional, yaque el mtex es readquirido antes
de que se inicie la ejecucin de cualquier gestor de
interrupciones.
Una variable de condicin es "sealada" por un hilo
despus de que el hilo cambie el estado de algn dato
compartido permitiendo que el predicado asociado se
haga cierto. Cuando una variable de condicin es
sealada, al menos uno de los hilos bloqueados en ella
pasa al estado preparado. Si ms de un hilo est
bloqueado en lavariable de condicin, el hilo con mayor
prioridad pasaral estado preparado. En particular, en
un sistema multiprocesador, puede ser ms eficiente
desbloquear ms de un hilo alaesperade lacondicin.
Una variable de condicin es una variable similar a la
variable de condicin empleadaen laimplementacin de
los monitores como tcnicade sincronizacin. Se suele
asociar un mtex a una variable de condicin cuando
sta se emplea. Cuando se espera por una variable de
condicin, se indica el mtex bloqueado asociado a la
seccin crtica a la que se desea acceder cuando se
cumpla la condicin. De esta forma la variable de
condicin y el mtex cooperan en laproteccin de una
regin crticacondicional.
- El mtex se emplea para realizar un cierre a corto
plazo, normalmente para proteger el acceso a las
regiones crticas.
- Lavariable de condicin se utilizaparaunaesperaa
largo plazo, en espera de algn recurso no disponible.
Por ello cuando se esperapor unacondicin, se liberael
mtex de acceso a la regin critica, pero se vuelve a
bloquear dicho mtex cuando se despiertalavariable de
condicin.
Variables globales
El problema de compartir las variables globales por
varios hilos puede provocar que generemos valores
incorrectos en sus valores, debido alaindeterminacin
9
del hilo que se ejecutar en cada momento. Existen
diversas soluciones aeste problema:
1) Prohibir lasvariablesglobales: Es algo ideal, pero genera
conflictos con el software existente.
2) Asignar variablesglobalesparticularesacadahilo: Cadahilo
tiene su propiacopiade lavariable global, lo que evita
los conflictos. Se creapues un nivel ms de visibilidad
correspondiente a las variables visibles por todos los
procedimientos de un hilo. El problemaes que no todos
los lenguajes tienen formas de expresar este tipo de
variables. Una solucin es asignar un bloque de
memoria a las variables globales y transferirla a cada
procedimiento del hilo como un parmetro adicional.
No es unasolucin elegante, pero funciona.
3) Crear nuevos procedimientos de biblioteca, para crear,
asignar y leer los valores de estas variables globales en
un hilo. Estaes laformaque suelen adoptar lamayora
de los paquetes de hilos. Las llamadas, de forma
abstracta, podran ser:
- create_global("puntero_variable") = Asigna un espacio de
almacenamiento paraun puntero de unavariable en un
reaespecial reservadaparael hilo que hizo lallamada.
El hilo que hizo la llamada es el nico que puede
acceder alavariable. Si otro hilo creaunavariable global
con el mismo nombre obtiene un espacio de
almacenamiento distinto, lo que evitaconflictos con el
yaexistente.
- set_global("puntero_variable", &valor) = Almacenael valor
de un puntero en el espacio de almacenamiento
reservado anteriormente.
- puntero_variable = read_global("puntero_variable") =
Devuelve ladireccin almacenadaen lavariable global,
paratener acceso al valor del dato.
Implementacin de un paquete de hilos
Aunque cada paquete de hilos puede tener una
implementacin distinta, existen dos formas bsicas de
implementacin de los hilos, y unaformamixta:
1. Implementacin a nivel usuario, en forma de
paquete o biblioteca de hilos, donde toda la
funcionalidad es parte del programa de
usuario. Esta implementacin puede ser ms
eficiente, yaque no se necesitaentrar al kernel
en cadallamada, pero complicalagestin de
seales y otras operaciones con los hilos.
Adems se necesitan dos planificadores, un
planificador de procesos (anivel kernel) y un
planificador de hilos (en el paquete de hilos, a
nivel usuario). Existen sin ningn soporte del
kernel y mantienen todo su estado en el
espacio de usuario. El kernel no conoce su
existencia por lo que no pueden ser
planificados para ejecutarse en mltiples
procesadores en paralelo.
2. Implementacin a nivel kernel, donde toda la
funcionalidad es parte del kernel del sistema
operativo. Esta implementacin simplifica el
control sobre las operaciones de los hilos y la
gestin de seales, pero aade gran
sobrecarga al ser necesario entrar y salir del
kernel en cadallamada. Este tipo de sistemas
son conocidos como sistemaspuroso sistemasde
unsolonivel, yaque el kernel es el responsable
de planificar todos los hilos.
3. Implementacin mixta, que consiste en
implementar una biblioteca de hilos, pero
apoyado en un modelo de hilos de nivel
kernel, que permite la ejecucin de los hilos
de usuario. Estos sistemas son conocidos
como sistemashbridoso sistemasadosniveles. El
kernel coopera con el paquete de hilos de
nivel usuario en la planificacin.
Normalmente el kernel planifica procesos
ligeros, llamados abreviadamente LWPs, y la
biblioteca de hilos planifica hilos de usuario
sobre LWPs.
Paquete de hilos de nivel usuario
El paquete se implementaen el espacio de usuario, sin
que el ncleo conozca su existencia. El ncleo sigue
manejando procesos con un nico hilo.
Figura3-9 Paquete de hilos anivel de usuario.
Los hilos se ejecutan en laparte superior de un sistemade
tiempo de ejecucin, que consiste en un conjunto de
procedimientos que gestionan los distintos hilos.
Cuando un hilo ejecuta una llamada al sistema, se
bloquea(duerme), realizaunaoperacin en un mtex, o
realiza alguna accin que provoca su suspensin, en
realidad llamaaun procedimiento del sistemade tiempo
de ejecucin. Este procedimiento es el que verificasi se
debe suspender el hilo. En ese caso, almacena los
registros del hilo en unatabla, localizaun nuevo hilo no
bloqueado para ejecutar, y restaura los registros del
nuevo hilo a partir de los valores almacenados en la
tabla. Se establecen tambin los valores del puntero de
pila y de programa, y entonces el hilo vuelve a
ejecutarse.
Si lamquinatiene unainstruccin paraalmacenar los
registros y otra para cargarlos, entonces todo el
intercambio de hilos se puede realizar en una sola
operacin. Esta conmutacin entre hilos es muy
superior, en velocidad, alaconseguidasi el intercambio
se realizase anivel del ncleo.
En un sistema operativo que soporta hilos a nivel de
usuario, una aplicacin puede ser 'multithreaded', esto
es, mltiples hilos de ejecucin pueden existir dentro de
un proceso. Normalmente, una limitacin de los hilos
de usuario es que slo un hilo, representando una
porcin de todo el programa, puede ejecutarse en un
momento dado. Cuando un proceso formado por hilos
es planificado, el contexto de un hilo de usuario se
enlazacon el proceso, y el proceso ejecutadicho hilo. Si
un hilo se bloquea o finaliza, otro hilo del mismo
proceso puede ser planificado en su lugar, con lo cual
no se pierde el quantum de tiempo asignado.
Los hilos de usuario pueden ser creados por
programadores de aplicaciones usando los APIs de hilos
proporcionados por unabibliotecade hilos. Estos APIs
permiten a los programadores crear, finalizar, y
sincronizar los hilos de un proceso. Lalibrerade hilos
puede tambin contener un planificador para los hilos
de usuario. Los hilos de usuario no son directamente
visibles por el kernel, son visibles slo en el espacio de
usuario. As pues, un hilo de usuario debe estar asociado
con un entidad del kernel planificable (como un
proceso) para tener acceso al procesador. En este
10
modelo, los procesos, no los hilos, son las entidades
planificables por el ncleo.
Una definicin de los hilos de nivel usuario se puede
encontrar en el dicho "muchos auno". Estadefinicin
se deriva de la naturaleza de la implementacin, pues
varios hilos pueden existir en un proceso, pero slo uno
se puede ejecutar en un momento dado.
Las principales ventajas de un paquete de hilos anivel
de usuario son:
Un paquete de hilos de nivel usuario se puede
implementar en un sistemaoperativo que no
soporte hilos, como puede ser UNIX.
El intercambio de hilos es ms rpido que las
indicaciones al ncleo (cambios de contexto
entre procesos), ya que a nivel de ncleo se
realizaun cambio de contexto completo.
Cada proceso puede tener un algoritmo de
planificacin distinto parasus hilos, adaptado
asus necesidades.
Presenta mejor escalabilidad, al no necesitar
reservar espacios para tablas, pila, etc. en el
readel ncleo, lo cual suele limitar el nmero
mximo de hilos en el sistema.
Paquete de hilos de nivel kernel
En este tipo de paquetes el ncleo gestionalos hilos. No
se necesitaun sistemade tiempo de ejecucin como en
el caso de los hilos anivel de usuario.
Figura3-10 Paquete de hilos anivel de ncleo.
Para cada proceso el ncleo tiene una tabla con una
entradapor cadauno de los hilos del proceso, con los
registros, estado, prioridades y otra informacin sobre
cadahilo. Lainformacin es lamismaque en los hilos a
nivel de usuario, slo que ahora se encuentra en el
espacio del ncleo y no en el espacio de usuario (dentro
del sistema de tiempo de ejecucin), por lo cual est
limitado. Las llamadas que pueden bloquear un hilo se
implementan como llamadas al sistema, lo que supone
un mayor coste que en el caso de nivel de usuario,
donde se realizaban llamadas a un procedimiento del
sistemade tiempo de ejecucin.
Si un hilo se bloquea, el kernel puede decidir entre
ejecutar otro hilo del mismo proceso (si alguno est
listo) o un hilo de otro proceso. En cambio en los hilos
a nivel de usuario, el sistema de tiempo de ejecucin
mantiene en ejecucin los hilos del propio proceso hasta
que el kernel les quita la CPU, o bien no existan ms
hilos del proceso listos paralaejecucin.
En un sistemaoperativo con soporte de hilos anivel del
kernel, los procesos no son entidades planificables, sino
que son los hilos las entidades planificables y los
procesos son slo contenedores lgicos para los hilos.
De estaforma, si unaaplicacin se estejecutando, cada
hilo de un proceso puede ejecutarse en un procesador
diferente, ya que el ncleo es capaz de planificar los
hilos individualmente.
Los hilos anivel del ncleo son creados por lalibrera
de hilos empleando llamadas al sistema de gestin de
hilos del ncleo. Estas llamadas al sistemapermiten ala
bibliotecade hilos crear, finalizar y sincronizar los hilos
del ncleo. Los hilos del ncleo son visibles tanto por el
ncleo como por lalibrerade hilos. El ncleo planifica
y gestiona estos hilos segn sus propias necesidades y
las necesidades de los servicios del ncleo.
Existen dos formas de hilos a nivel de ncleo en una
implementacin mixta:
Uno auno: En este modelo, existe un hilo del
kernel por cadahilo de usuario en el sistema.
Los hilos, no los procesos, son las entidades
planificables, y cadahilo de un proceso puede
ser planificado en un procesador diferente.
As pues, este modelo soportaprocesamiento
paralelo.
Varios a varios: Este modelo es la
generalizacin del modelo varios a uno y el
modelo uno a uno. Este modelo puede
soportar:
- Un hilo del ncleo por cadahilo de usuario.
- Mltiples hilos de usuario multiplexados en un slo
hilo del ncleo.
- Cualquier nmero de combinaciones.
Este modelo soporta proceso paralelo, por ser un
modelo de hilos anivel del ncleo.
Unade las principales ventajas de un sistemaoperativo
que soporto hilos anivel del ncleo es laposibilidad de
ejecutar el cdigo de una aplicacin multihilo
concurrentemente en varios procesadores.
Estructura bsica
Las estructuras manejadas por el paquete de hilos deben
estar protegidas para no ser modificadas de forma
inconsistente durante lagestin de eventos asncronos o
seales. Para ello, la implementacin del paquete debe
garantizar que laejecucin de las secciones crticas del
cdigo del paquete slo pueden ser ejecutadas por un
hilo al mismo tiempo. Existen dos tcnicas bsicas para
implementar laexclusin mutuadentro de labiblioteca
de hilos:
el monitor monoltico, que consiste en considerar
a toda la biblioteca como un gran monitor.
En esta tcnica se emplea pues un bloqueoa
granescala.
Unatcnicaalternativa, seraemplear bloqueos
apequeaescala, asociando un semforocon cada
estructura de datos global. Esta tcnica
permite una mayor concurrencia en un
entorno multiprocesador pero se necesitan
ms operaciones para garantizar la exclusin
mutua para cada una de las estructuras
globales de formaindividual. Por ello no suele
emplearse en bibliotecas pensadas para
sistemas uniprocesador.
Normalmente existen dos flags o variables especiales en
labibliotecade hilos:
Kernel flag: Indica si se est en el modo
protegido o kernel del paquete. A partir de
ese momento las operaciones son realizadas
garantizando laexclusin mutuaentre hilos.
Dispatcher flag: Indica si ser invocado el
dispatcher al salir del modo protegido del
paquete. El flag es activado cuando se
planifica un nuevo hilo o cuando se recibe
unaseal mientras se esten modo protegido.
Parasalir del modo protegido, simplemente se desactiva
el kernel flag si el dispatcher flag no estactivado. En
otro caso, se invocael dispatcher, que puede provocar
11
un cambio de contexto aotro hilo, y permite gestionar
seales recibidas mientras se esten modo protegido.
Envo de seales
En lamayor parte de los paquetes, el envo de seales
de nivel proceso alos hilos estfuertemente relacionado
con el dispatcher. En particular, las seales recibidas
mientras se esten modo protegido son gestionadas de
formadiferente que las seales recibidas mientras se est
en modo usuario, aunque comparten un gestor universal de
seales a nivel proceso, que es establecido durante la
inicializacin del paquete de hilos paratodas las seales
enmascarables del sistema:
a) Gestinenmodousuario: Cuando unaseal es capturada
por el gestor universal y el kernel flag no estactivado
(se esten modo usuario), se entraen modo protegido
activando el kernel flag, todas las seales son habilitadas,
y se llamaaunarutinaque primero dirige laseal al hilo
apropiado y despus llama al dispatcher. El control
puede que no regrese inmediatamente al hilo
interrumpido si laseal hace que el hilo destinatario de
mayor prioridad, sea seleccionado por el planificador
parasu ejecucin.
b) Gestin en modo protegido: Cuando una seal
es capturada por el gestor universal y el kernel
flag est activado (se est en modo protegido), la
seal recibida es anotada y su gestin es diferida
hasta que se llama al dispatcher. El control es
devuelto inmediatamente al punto del hilo
interrumpido regresando del gestor universal,
que previamente habilita nuevamente las seales
a nivel de proceso.
El dispatcher
Bajo circunstancias normales, unallamadaal dispatcher
seleccionarel siguiente hilo elegible paraejecucin del
conjunto de hilos listos de acuerdo con la poltica de
planificacin. Si el hilo seleccionado es distinto del hilo
actual en ejecucin se realiza un cambio de contexto,
que implicalas siguientes acciones:
Salvar los registros del procesador en lapila.
Cargar el puntero de contexto con la
direccin del contexto del nuevo hilo.
Cargar lavariable global errno con lavariable
del hilo errno.
Cargar los registros del nuevo hilo y conmutar
al contexto del nuevo hilo.
Transferir el control al nuevo hilo.
Cuando se vaaejecutar un hilo que no fue interrumpido
por unaseal, el contexto es conmutado al estado local
del nuevo hilo. Antes de que el control seatransferido al
nuevo hilo, el kernel flag y el dispatcher flag son
desactivados y se comprueba si se recibieron seales
mientras se estaba en modo protegido. Si no se
recibieron seales, el control es transferido al nuevo hilo
; en otro caso, las seales son gestionadas y se produce
otro intento de ejecutar un hilo. Como la gestin de
seales puede cambiar el hilo a ser ejecutado a
continuacin, el cambio de contexto debe ser reiniciado.
Cuando se vaaejecutar un hilo que fue interrumpido
por una seal, el gestor universal de seales
permanecerpendiente en lacimade lapiladel hilo. Por
lo tanto, el gestor deshabilitatodas las seales antes de
realizar el cambio de contexto. Cuando el hilo retome el
control retornar del gestor universal, habilitar todas
las seales de nuevo y regresar al marco de
interrupcin del sistema operativo que restaurar el
estado global (registros, palabra de estado, etc.). Es
imprescindible deshabilitar las seales antes de cambiar
al contexto de un hilo interrumpido para evitar un
crecimiento ilimitado de lapila, yaque de otraforma, el
gestor universal podraser interrumpido por unanueva
instanciade gestor universal antes de que el hilo pudiese
regresar de laprimerainstancia, y as sucesivamente.
Gestin de seales
Las seales de nivel proceso que fueron capturadas en
modo protegido son diferidas hasta que es llamado el
dispatcher, en otro caso son gestionadas
inmediatamente. La gestin de la seal implica
determinar el hilo receptor y laaccin arealizar parala
seal. El receptor es determinado de acuerdo con el
modelo deenvo deseales, que describe cuando un hilo
recibe unaseal y como se resuelven los conflictos entre
mltiples hilos.
A continuacin se presentael modelo de resolucin de
conflictos empleado en el paquete Pthreads de Frank
Mueller y tambin en el paquete Pthreads de Chris
Provenzano:
3. si la seal es dirigida especficamente a un
hilo, dicho hilo es el receptor, sino
4. si la seal es enviada de forma sncrona, se
dirige al hilo que laprovoc, sino
5. si la seal fue causada por la finalizacin de
un reloj, se dirige al hilo que inici el reloj,
sino
6. si la seal fue causada por la finalizacin de
una E/ S, se dirige al hilo que realiz la
peticin, sino
7. laseal permanece pendiente anivel proceso
hastaque se puedaseleccionar un hilo que la
reciba. La eleccin de un hilo arbitrario es
suficiente para cumplir con el estndar
POSIX Threads. En este caso, se realizauna
bsqueda secuencial en la lista de todos los
hilos hastaque se llegaal final o se encuentra
un hilo que tiene habilitadalaseal.
En dichos paquetes, si un hilo es seleccionado como
receptor de unaseal, se elige unaaccin arealizar de la
siguiente forma:
1. si el hilo deshabilit la seal, la seal
permanece pendiente parael hilo, sino
2. si la seal es una seal de alarma y fue
provocada por la finalizacin de un reloj, el
hilo seleccionado pasaal estado preparado si
fue suspendido, o, es colocado al final de la
lista de preparados si la finalizacin del
tiempo fue provocada por el consumo del
quantum de tiempo asignado al hilo, sino
3. si el hilo fue suspendido en una llamada
sigwait, el hilo pasaal estado preparado y las
seales especificadas en lallamadasigwait son
deshabilitadas parael hilo, sino
4. si existe un gestor registrado paralaseal, se
instala una llamadafalsao fakecall parael hilo
seleccionado, las seales son deshabilitadas
segn lamscaraespecificadaen sigaction, y
el hilo pasaal estado preparado, sino
5. si laseal es laseal de cancelacin, se instala
unallamadafalsaapthread_exit en lapila, y el
hilo pasaal estado preparado, sino
12
6. si laaccin definidaparalaseal es ignorar la
seal, no se realiza ninguna accin y se
descartalaseal, sino
7. si laaccin definidaparalaseal es laaccin
por defecto, se realiza la accin por defecto
definidaparael proceso.
Los gestores de seales de hilo (gestores de usuario)
instalados mediante una llamada a sigaction son
invocados atravs de un mecanismo de llamada falsa o
fakecall. Unallamadafalsaintroduce un entorno en la
pilay establece el entorno paraque acte como si el hilo
hubiese llamado explcitamente aunafuncin.
La utilizacin de las llamadas falsas como mecanismo
para invocar gestores de usuario est motivado por la
restriccin que obligaaque los gestores de usuario sean
ejecutados con el nivel de prioridad del hilo
correspondiente. Por lo tanto, en vez de realizar una
llamadaexplcitaal gestor de usuario cuando se recibe
unaseal de proceso, laejecucin del gestor de usuario
es diferidahastaque el hilo receptor seaejecutado.
Bsicamente el mecanismo es el siguiente:
El cdigo de usuario es interrumpido por una
seal provocando que el sistema operativo
cree un nuevo entorno que salvael estado en
el punto de interrupcin e invoca al gestor
universal de seales de labibliotecade hilos,
el cual llamaal dispatcher.
El dispatcher cambiaaunapilatemporal pero
permanece activo.
Mientras se ejecuta en la pila temporal, la
seal es dirigidaal hilo (en este caso, el hilo
interrumpido), y un nuevo entorno envoltorio
es creado en lacimade lapiladel hilo.
El contador de programay el puntero de pila
del hilo tienen que ser actualizados para
reflejar el nuevo entorno de lallamadafalsa,
que ejecutar el envoltorio cuando el hilo
recupere el control.
El envoltorio realizalas siguientes acciones:
8. Si el gestor de usuario interrumpi
una espera condicional, el mtex
asociado es readquirido y laespera
condicional finalizada.
9. Lavariable errno del hilo es salvada.
10. El gestor de usuario es llamado.
11. La variable errno del hilo es
restaurada.
12. La mscara de seales de hilo
solicitada es restaurada, y las
seales pendientes para el hilo y
para el proceso son gestionadas si
estn habilitadas.
13. El control es devuelto al punto de
lainterrupcin o aunainstruccin
cuya direccin puede ser
opcionalmente especificada por el
gestor de usuario. Laposibilidad de
redirigir el control a una direccin
especificadaes unacaractersticano
requerida por el estndar POSIX
Threads pero dejadichaposibilidad
abierta, y en algunas ocasiones es
imprescindible, como ocurre con la
implementacin Pthreads de Frank
Mueller parasoportar el sistemade
tiempo de ejecucin de Ada.
Implementacin de mtex
Los mtex deben ser implementados paraproporcionar
exclusin mutua de la forma ms eficiente posible.
Idealmente, unainstruccin atmicadel tipo Test-and-
SeT (TST) debera ser suficiente para su
implementacin, pero desafortunadamente esto no es
suficiente y produciraalgunas deficiencias:
El estndar POSIX Threads especifica
protocolos ms complejos opcionales como la
herencia de prioridades para evitar el
problema de la inversin de prioridades, que
requiere que el propietario del mtex sea
guardado con laoperacin de bloqueo.
Las implementaciones hardware de las
instrucciones TST producen a veces peor
rendimiento que secuencias atmicas de
instrucciones reiniciables para implementar
exclusin mutuaen un sistemauniprocesador.
El protocolo de herenciade prioridad requiere que si un
hilo de mayor prioridad se suspende en un mtex
debido alaesperapor un hilo de menor prioridad que
posee el mtex, el hilo de menor prioridad hereda la
mayor prioridad hastaque se desbloqueael mtex. De
esta forma, la asociacin de propiedad de un mtex
permite que un hilo de mayor prioridad incremente la
prioridad del hilo que posee el mtex. Existen varias
formas de implementacin para guardar el propietario
de un mtex de forma atmica junto al bloqueo del
mtex.
Se garantiza que una secuencia atmica reiniciable es
atmica aumentando el gestor de seales. Si dicha
secuenciafue interrumpidapor el gestor de seales, la
secuenciaatmicaes reiniciadaen el gestor de seales ;
en otro caso no se realiza ninguna accin. Para la
implementacin del bloqueo de un mtex, debe
garantizarse que existe un propietario asociado con cada
mtex bloqueado en todo momento.
Este esquema no es extensible a un sistema
multiprocesador. En este caso, las instrucciones TST
son imprescindibles ya que son la nica forma de
garantizar actualizaciones atmicas en lamemoria. Pero
todava se pueden emplear las secuencias atmicas
reiniciables para grabar la propiedad junto con las
instrucciones TST, permaneciendo en el bucle de espera
del hilo hasta que se haya pasado el intervalo limite
entre el bloqueo del mtex y el establecimiento del
propietario, parael hilo que adquiere el mtex.
Problemas de implementacin
Existen numerosos problemas alahorade implementar
un paquete de hilos. Algunos problemas son especficos
de una implementacin de nivel usuario, ya que se
intenta que el sistema operativo est involucrado lo
menos posible. Otros problemas son inherentes a la
implementacin en s, independientemente del nivel.
Algunos problemas son ms fciles de resolver, otros no
tanto y son resueltos de formas distintas segn la
13
implementacin. Adems, la adopcin del estndar
POSIX Thread no resuelve todos los problemas de
implementacin, yaque el estndar dejamuchos detalles
libres alaimplementacin concreta.
Paquetes de nivel usuario
A pesar de su mejor rendimiento, los paquetes que
implementan hilos a nivel de usuario presentan
importantes problemas:
1) La implementacin de las llamadas al sistema
con bloqueo: Los sistemas operativos sin soporte de
hilos no suelen proporcionar llamadas al sistema sin
bloqueo, equivalentes a las llamadas con bloqueo
empleadas habitualmente.
Si un hilo realizaunaaccin que produce un bloqueo,
en unaimplementacin anivel de ncleo, el hilo realiza
unallamadaal kernel, y ste bloqueael hilo e iniciaotro;
en cambio, en laimplementacin anivel de usuario, no
se puede permitir que el hilo realice directamente la
llamadaal kernel yaque suspenderatodo el proceso, es
decir, todos los hilos del proceso. Se debe pues permitir
que todos los hilos realicen llamadas con bloqueo, pero
evitando que un hilo bloqueado afecte a los dems.
Empleando llamadas al sistema con bloqueo no se
podraconseguir este objetivo.
Una solucin consiste en modificar las llamadas al
sistema para que no utilicen el bloqueo, pero esto es
complicado, pues se deben realizar cambios en el
sistema operativo, y se perdera precisamente una
importante ventajade los hilos anivel de usuario, como
es su implementacin en sistemas operativos ya
existentes.
Existe otrasolucin cuando se puede conocer apriori si
una llamada se bloquear. En algunas versiones de
UNIX existe unallamadaselect que realizaestaconsulta.
Se puede, entonces, reemplazar el procedimiento de
biblioteca, por ejemplo, readpor otro que primeramente
realice la llamada al sistema select y despus realice la
llamada al sistema read slo en caso de que se tenga
garanta de no bloqueo. Si la llamada read se va a
bloquear (lo cual se conoce mediante lallamadaselect) no
se realiza y se ejecuta otro hilo del proceso. En la
siguiente ocasin que el sistemade tiempo de ejecucin
obtiene el control, puede volver a intentar la llamada
read (verificar si habr o no bloqueo). Este mtodo
necesitaque se reescriban parte de los procedimientos
de biblioteca de las llamadas al sistema, es algo
ineficiente y poco elegante, pero no existen muchas ms
soluciones al respecto. El cdigo encargado de realizar
laverificacin de lallamada, que se colocajunto con la
llamadaal sistema, se suele llamar jacket.
Marsh and Scott [MAR91] han realizado algunas
sugerencias para resolver algunos problemas asociados
con los hilos de nivel usuario, definiendo un interfaz
genrico entre el kernel del sistemaoperativo y el nivel
de usuario, que proporciona una comunicacin rpida
entre las actividades de ambos niveles. As por ejemplo,
cuando se produce unasolicitud de E/ S sin bloqueo, el
kernel asocialasolicitud con un dato (el hilo que realiza
la llamada), de forma que el planificador de hilos de
nivel usuario puedaser notificado de que laoperacin
de E/ S se hacompletado. Gracias aeste dato se elimina
la necesidad de demultiplexar la seal en el nivel de
usuario con lo cual se incrementalarespuestaaeventos
asncronos de forma considerable sin complicar
indebidamente el kernel del sistemaoperativo.
2) Ejecucin paralela de hilos del mismo proceso:
Otro problemacon los paquetes de hilos anivel usuario
es que cuando un hilo comienzasu ejecucin, el resto de
los hilos del proceso no puede ejecutarse, amenos que
el primer hilo libere voluntariamente laCPU, mientras
que en los paquetes de nivel kernel pueden ejecutar
varios hilos del mismo proceso de forma paralela. En
los paquetes anivel de ncleo, el planificador se ejecuta
peridicamente debido alas interrupciones de reloj, y se
permite la planificacin round-robin, a diferencia del
paquete anivel usuario, en el que en un nico proceso
no existen interrupciones del reloj, imposibilitando la
planificacin round-robin, y la nica oportunidad que
tiene el planificador de ejecutarse es que un hilo entre en
el sistemade tiempo de ejecucin por voluntad propia.
Unaposible solucin seraque el sistemade tiempo de
ejecucin solicite una seal al reloj (interrupcin) por
cadasegundo con el fin de obtener el control, pero esto
resulta en una programacin problemtica, y adems
puede interferir con unainterrupcin empleadaparaun
hilo.
3) Aplicaciones de bloqueo: Las aplicaciones en las
que es ms interesante el uso de hilos son aquellas
donde los hilos se bloquean habitualmente, ya que
realizan continuas llamadas al sistema. Si los hilos del
proceso estn bloqueados, como el nico trabajo que
realiza el sistema de tiempo de ejecucin es conmutar
entre hilos, pero todos los hilos del proceso se
encuentran bloqueados, no hay razn para verificar la
seguridad de las llamadas al sistema, sino que lo que
interesara sera devolver al control al kernel, para que
planificase otro proceso, mientras tanto.
4) La inversin de prioridades es difcil de resolver.
La combinacin de prioridades y secciones crticas
puede causar un fenmeno llamado inversindeprioridad,
unasituacin en lacual un hilo de mayor prioridad no
puede expulsar aotro de menor prioridad que ejecutasu
seccin crtica. La inversin de prioridad puede
provocar retrasos largos e inaceptables en aplicaciones
de usuario o microkernel multihilo. Adems, no permite
garantizar las restricciones de tiempo impuestas por los
sistemas de tiempo real. Por otro lado, implementar la
herenciade prioridades supone un gran esfuerzo en el
caso de un mtex compartido entre hilos de procesos
diferentes, ya que sera necesario establecer alguna
formade comunicacin entre las bibliotecas de ambos
procesos.
5) Primitivas de sincronizacin globales: Lamayora
de las implementaciones de bibliotecas de hilos de nivel
usuario carecen de mtex y variables de condicin
compartidos que puedan ser utilizados entre procesos,
aunque el estndar POSIX Threads los define. Estos
objetos pueden ser implementados de dos formas:
Apoyndose en las primitivas de
comunicacin entre procesos existentes.
Empleando un espacio de datos compartido
por los procesos, que almacene los objetos de
sincronizacin compartidos. Esta solucin
parece proporcionar un mejor rendimiento.
6) Aumento del rendimiento: En la mayora de las
implementaciones, laobtencin del espacio paralapilay
el contexto o bloque de control del hilo (Thread
Control Block, TCB) llevael 70% del tiempo empleado
en su creacin. Esta velocidad de creacin puede
aumentarse si el paquete posee una zona de memoria
paraTCBs y pila, que es empleadadurante lacreacin
de los hilos.
14
Problemas generales
Existen problemas de implementacin que afectan tanto
a los hilos a nivel usuario como a los hilos a nivel
ncleo, y que cada paquete concreto ha resuelto de
forma particular. Los principales problemas son los
siguientes:
8. Procedimientos de biblioteca no
reentrantes: Un obstculo ms problemtico
en la utilizacin de los hilos es hacer
reentrantes las bibliotecas de C. Muchas
llamadas de biblioteca emplean informacin
de estado global, algunos interfaces no son
reentrantes, las macros tienen que ser
modificadas, y lainterrupcin debidaaseales
debe ser considerada sin sacrificar el
rendimiento. Como ejemplo, podemos poner
un buffer en el que un hilo prepara un
mensaje para enviar a la red, pero antes de
hacerlo se produce un cambio de hilo, y el
nuevo hilo reescribe sobe el buffer del
anterior. Este aspecto es tratado por Jones
[JON91].
9. Otros procedimientos cruciales, como
mallocen UNIX, emplean tablas cruciales del
sistema, sin emplear regiones crticas
protegidas, ya que fueron escritos para
sistemas de un nico hilo, donde esto no era
necesario. Para solucionar esto habra que
reescribir todalabibliotecadel sistema. Otra
solucin consiste en proporcionar a cada
procedimiento que lo necesite un jacket que
cierre un mtex global al iniciar el
procedimiento. Con ello se consigue que est
activo un nico hilo de labibliotecaen cada
instante. De esta forma, la biblioteca se
convierte en un gran monitor.
10. La gestin de las seales tambin resulta
problemtica. La sobrecarga debida a la
gestin de seales independiente para cada
hilo complica el diseo y la implementacin
del paquete de hilos de forma considerable.
Puede ocurrir que varios hilos traten de
capturar lamismaseal pararealizar acciones
diferentes, lo cual es incompatible. Esta
situacin puede surgir si uno o ms hilos
emplean procedimientos estndar de
biblioteca, y otros en cambio utilizan
procedimientos propios escritos por el
usuario. Normalmente es difcil gestionar las
seales en un ambiente con un nico hilo,
pero el paso aun ambiente de mltiples hilos
no facilita su manejo, y ms si tenemos en
cuentaque las seales son un concepto tpico
de proceso, sobre todo si el ncleo no conoce
laexistenciade los hilos como ocurre en los
paquetes anivel usuario. En lamayorade las
implementaciones de hilos, cadahilo tiene su
propiamscarade seales, lo que le permite
bloquear o desbloquear seales, pero cada
hilo no puede tener su propio gestor de
seales. Normalmente la solucin es
implementar un hilo que se encargue slo de
lagestin de seales, y deshabilitar las seales
en el resto de hilos, para que no sean
capturadas por ellos. Adems se debe tener
cuidado con lamscarade seales, alahora
de enviar seales aotros hilos del proceso, ya
que la seal ser captura por el primer hilo
que se ejecute y tengahabilitadadichaseal.
11. La cancelacin de un hilo por parte de otro,
cuando yano es necesario que sigarealizando
ms trabajo es problemtica, ya que el hilo
cancelado puede encontrarse en una regin
crticay al ser cancelado no liberaun recurso
que puede necesitar otro hilo que esperapor
l. Una solucin suele ser emplear la
cancelacin diferida, es decir colocar unaserie
de puntos de cancelacin en los cuales se
comprueba si el hilo ha sido cancelado, en
cuyo caso se procede asu destruccin. Pero si
el hilo no se encuentra en un punto de
cancelacin, no puede ser cancelado hastaque
no llegue a uno de esos puntos, aunque la
cancelacin haya sido solicitada con
anterioridad.
Ventajas de los hilos
La principal ventaja de los hilos es el rendimiento.
Normalmente el rendimiento es unacantidad percibida
y no dada. Unas aplicaciones se beneficiarn de los hilos
mientras que otras no. Como se suele decir "el nmero
de kilmetros puede variar".
Existen un gran nmero de ventajas para emplear los
hilos de usuario as como los hilos del ncleo:
14. Ejecucin paralela: Los hilos de nivel kernel
se pueden ejecutar realmente en paralelo en
mquinas SMP (Symmetric Multiprocessors).
Adems el mismo cdigo binario es vlido
tanto para una mquina de un procesador
como unamquinamultiprocesador.
15. Ejecucin de cdigo asncrono: Ya que
existen mltiples hilos de ejecucin en un
programaconstruido con hilos, es posible que
otro hilo del mismo proceso sea planificado
para ejecutar en el caso de que el hilo de
ejecucin actual se bloquee. Esto incrementa
laprobabilidad de que laaplicacin asociada
se ejecute mucho ms rpido. Normalmente
existen algunas cosas atener en cuenta:
1. En el modelo de hilos de usuario,
algunos bloqueos bloquearn todo
el proceso y se planificar un
proceso diferente.
2. En el modelo de hilos de ncleo, es
posible que un hilo de otro proceso
sea planificado cuando sucede un
bloqueo del hilo actual.
3. En ambos modelos, un hilo puede
bloquearse y pueden no existir
otros hilos listos paraejecutarse en
el proceso, por cualquier tipo de
razones.
As pues, el incremento del rendimiento no siempre est
garantizado, aunque al menos, el uso de los hilos puede
incrementar laprobabilidad de un mejor rendimiento.
12. Recursos compartidos: Los hilos
comparten la mayora de los recursos en un
proceso. Comparten el acceso alos ficheros,
memoria compartida, y el espacio de
direcciones virtual. El empleo de los hilos
permite a los programadores conservar los
recursos del sistema. El rendimiento puede
beneficiarse tambin porque los recursos
compartidos entre hilos necesitan menos
15
gestin que los recursos compartidos entre
procesos.
13. Velocidad de las operaciones con hilos:
Los hilos tienen un menor contexto que los
procesos, as pues, las operaciones con hilos
son generalmente ms rpidas que las
operaciones similares con procesos. En
especial, lacreacin, finalizacin y cambio de
contexto de un hilo, son operaciones ms
rpidas con los hilos que con los procesos.
Como ejemplo, en los procesadores de
propsito general (SPARC, MIPS, ALPHA,
HP-PA, x86) el cambio de contexto entre
hilos de un mismo proceso llevadel orden de
50us. mientras que el cambio de contexto
entre hilos de distintos procesos lleva del
orden de 100us. Estos tiempos son muy
inferiores al tiempo de cambio de contexto
completo entre procesos. As en Solaris la
creacin de un proceso es unas 30 veces ms
lento que lacreacin de un hilo, las variables
de sincronizacin son unas 10 veces ms
lentas y el cambio de contexto unas 5 veces
ms lento.
14. Tiempo de respuesta: Si es posible separar
operaciones en un programa, los hilos se
pueden emplear paramejorar los tiempos de
respuesta de la aplicacin. Por ejemplo,
supongamos que estamos usando unautilidad
de correo electrnico. En unaversin de un
solo hilo, mientras almacenamos un mensaje
podemos apreciar algn retraso antes de que
lainterfaz de usuario searefrescada. Esto es
porque el programa est primero haciendo
una operacin de E/ S para almacenar el
mensaje y despus refresca la pantalla. Estas
operaciones las realiza de forma secuencial.
Normalmente, si esta aplicacin fuese una
versin programadacon varios hilos, un hilo
podra gestionar la E/ S mientras otro hilo
gestiona la interfaz de usuario. Estas
operaciones pueden funcionar en paralelo,
con laconsiguiente gananciaen el tiempo de
respuesta.
15. Programacin natural: Estaventajano est
relacionada con el rendimiento, pero es
importante. En algunas aplicaciones, el
diseador puede necesitar instrucciones del
tipo 'goto' y otros mtodos para superar las
limitaciones de la programacin secuencial
tradicional. Sin embargo, con los hilos, el
programador no est limitado a emplear un
modelo de ejecucin secuencial. As, las
limitaciones de la programacin secuencial
pueden solucionarse de forma ms intuitiva,
menos compleja y ms natural, incluso
empleando otros modelos de programacin,
como la programacin concurrente. Adems
muchos problemas son ms fciles de
plantear y programar con un modelo de hilos
debido asu estructuraconcurrente.
16. Existe un estndar (POSIX 1003.1c) lo que
permite hacer a las aplicaciones portables
entre distintas plataformas. El mismo cdigo
fuente es vlido paradistintas plataformas.
17. Objetos distribuidos: Con la aparicin del
estndar de objetos distribuidos CORBA, los
hilos toman un papel especial e importante.
Los objetos distribuidos tienen unaestructura
multihilo inherentemente. Cada vez que se
pide que un objeto realice una accin, el
objeto ejecuta la accin mediante un hilo
independiente, de formaque el objeto puede
haber ms de un hilo al mismo tiempo.
Adems los servidores de objetos se pueden
construir con hilos de forma ms efectiva y
con un mayor rendimiento.