Hilos de ejecucin o thread

Un hilo de ejecucin o thread , en sistemas operativos, es una

caracterstica que permite a una aplicacin realizar varias tareas
concurrentemente. Los distintos hilos de ejecucin comparten una serie
de recursos tales como el espacio de memoria, los archivos abiertos,
situacin de autenticacin, etc. Esta tcnica permite simplificar el diseo de
una aplicacin que debe llevar a cabo distintas funciones simultneamente.
Los hilos de ejecucin que comparten los mismos recursos, sumados a estos
recursos, son en conjunto conocidos como un proceso. El hecho de que los
hilos de ejecucin de un mismo proceso compartan los recursos hace que
cualquiera de estos hilos pueda modificar stos. Cuando un hilo modifica un
dato en la memoria, los otros hilos acceden e ese dato modificado
inmediatamente a en la siguiente figura podemos observar un ejemplo de
un hilo de ejecucin.

Lo que es propio de cada hilo es el contador de programa, la pila de

ejecucin y el estado de la CPU (incluyendo el valor de los registros).
El proceso sigue en ejecucin mientras al menos uno de sus hilos de
ejecucin siga activo. Cuando el proceso es terminado, todos sus hilos de
ejecucin tambin lo son. Asimismo en el momento en el que todos los hilos
de ejecucin finalizan, el proceso no existe ms y todos sus recursos son
liberados.
Algunos lenguajes de programacin tienen caractersticas de diseo
expresamente creadas para permitir a los programadores lidiar con hilos de
ejecucin (como Java). Otros (la mayora) desconocen la existencia de hilos
de ejecucin y stos deben ser creados mediante llamadas
de biblioteca especiales que dependen del sistema operativo en el que
estos lenguajes estn siendo utilizados (como es el caso del C y del C++).
Un ejemplo de la utilizacin de hilos es tener un hilo atento a la interfaz
grfica (iconos, botones, ventanas), mientras otro hilo hace una larga
operacin internamente. De esta manera el programa responde de manera
ms gil a la interaccin con el usuario. Tambin pueden ser utilizados por
una aplicacin servidora para dar servicio a mltiples clientes de procesos.
Diferencias entre hilos y procesos

Los hilos se distinguen de los tradicionales procesos en que los procesos son
generalmente independientes, llevan bastante informacin de estados, e
interactan slo a travs de mecanismos de comunicacin dados por
el sistema. Por otra parte, muchos hilos generalmente comparten otros
recursos directamente. En muchos de los sistemas operativos que proveen
facilidades para los hilos, es ms rpido cambiar de un hilo a otro dentro del
mismo proceso, que cambiar de un proceso a otro. Este fenmeno se debe a
que los hilos comparten datos y espacios de direcciones, mientras que los
procesos al ser independientes no lo hacen. Al cambiar de un proceso a otro
el sistema operativo (mediante el dispatcher) genera lo que se conoce como
overhead, que es tiempo desperdiciado por el procesador para realizar
un cambio de modo (mode switch), en este caso pasar del estado de
Running al estado de Waiting o Bloqueado y colocar el nuevo proceso en
Running. En los hilos como pertenecen a un mismo proceso al realizar un
cambio de hilo este overhead es casi despreciable.
Sistemas operativos como Windows NT, OS/2 y Linux (2.5 o superiores) han
dicho tener hilos 'baratos', y procesos 'costosos' mientras que en otros
sistemas no hay una gran diferencia.
Funcionalidad de los hilos
Al igual que los procesos, los hilos poseen un estado de ejecucin y pueden
sincronizarse entre ellos para evitar problemas de compartimiento de
recursos. Generalmente, cada hilo tiene una tarea especifica y determinada,
como forma de aumentar la eficiencia del uso del procesador.
Estados de un hilo
Los principales estados de los hilos son: Ejecucin, Listo y Bloqueado. No
tiene sentido asociar estados de suspensin de hilos ya que es
un concepto de proceso. En todo caso, si un proceso est expulsado de la
memoria principal (ram), todos sus hilos debern estarlo ya que todos
comparten el espacio de direcciones del proceso.
Cambio de estados
Creacin: Cuando se crea un proceso se crea un hilo para ese
proceso. Luego, este hilo puede crear otros hilos dentro del mismo proceso.
El hilo tendr su propio contexto y su propio espacio de pila, y pasara a la
cola de listas.

Bloqueo: Cuando un hilo necesita esperar por un suceso, se bloquea

(salvando sus registros). Ahora el procesador podr pasar a ejecutar otro
hilo que est en la cola de Listos mientras el anterior permanece bloqueado.

Desbloqueo: Cuando el suceso por el que el hilo se bloque se

produce, el mismo pasa a la cola de Listos.

Terminacin: Cuando un hilo finaliza se liberan tanto su contexto

como sus pilas.
Ventajas de los hilos contra procesos
Si bien los hilos son generados a partir de la creacin de un proceso,
podemos decir que un proceso es un hilo de ejecucin, conocido como
Monohilo. Pero las ventajas de los hilos se dan cuando hablamos de
Multihilos, que es cuando un proceso tiene mltiples hilos de ejecucin los
cuales realizan actividades distintas, que pueden o no
ser cooperativas entre s. Los beneficios de los hilos se derivan de las
implicaciones de rendimiento.

1.

Se tarda mucho menos tiempo en crear un hilo nuevo en un proceso

existente que en crear un proceso. Algunas investigaciones llevan al
resultado que esto es as en un factor de 10.

2.

Se tarda mucho menos en terminar un hilo que un proceso, ya que

cuando se elimina un proceso se debe eliminar el BCP del mismo,
mientras que un hilo se elimina su contexto y pila.

3.

Se tarda mucho menos tiempo en cambiar entre dos hilos de un

mismo proceso

4.

Los hilos aumentan la eficiencia de la comunicacin

entre programas en ejecucin. En la mayora de los sistemas en la
comunicacin entre procesos debe intervenir el ncleo para ofrecer
proteccin de los recursos y realizar la comunicacin misma. En cambio,
entre hilos pueden comunicarse entre s sin la invocacin al ncleo. Por lo
tanto, si hay una aplicacin que debe implementarse como un conjunto
de unidades de ejecucin relacionadas, es ms eficiente hacerlo con una
coleccin de hilos que con una coleccin de procesos separados.

Sincronizacin de hilos
Todos los hilos comparten el mismo espacio de direcciones y otros recursos
como pueden ser archivos abiertos. Cualquier modificacin de un recurso
desde un hilo afecta al entorno del resto de los hilos del mismo proceso. Por
lo tanto, es necesario sincronizar la actividad de los distintos hilos para que
no interfieran unos con otros o corrompan estructuras de datos.
Una ventaja de la programacin multihilo es que los programas operan con
mayor velocidad en sistemas de computadores con mltiples CPUs
(sistemas multiprocesador o a travs de grupo de mquinas) ya que los
hilos del programa se prestan verdaderamente para la ejecucin
concurrente. En tal caso el programador necesita ser cuidadoso para evitar
condiciones de carrera (problema que sucede cuando diferentes hilos o
procesos alteran datos que otros tambin estn usando), y otros
comportamientos no intuitivos. Los hilos generalmente requieren reunirse
para procesar los datos en el orden correcto. Es posible que los hilos
requieran de operaciones atmicas para impedir que los datos comunes
sean cambiados o ledos mientras estn siendo modificados, para lo que
usualmente se utilizan los semforos. El descuido de esto puede generar
interbloqueo.
Formas de multihilos
Los sistemas operativos generalmente implementan hilos de dos maneras:
Multihilo apropiativo: permite al sistema operativo determinar cundo
debe haber un cambio de contexto. La desventaja de esto es que el sistema
puede hacer un cambio de contexto en un momento inadecuado, causando
un fenmeno conocido como inversin de prioridades y otros problemas.
Multihilo cooperativo: depende del mismo hilo abandonar
el control cuando llega a un punto de detencin, lo cual puede traer
problemas cuando el hilo espera la disponibilidad de un recurso.
El soporte de hardware para multihilo desde hace poco se encuentra
disponible. Esta caracterstica fue introducida por Intel en el Pentium 4, bajo
el nombre de HyperThreading.
Usos ms comunes

Trabajo interactivo y en segundo plano

Por ejemplo, en un programa de hoja de clculo un hilo puede estar
visualizando los mens y leer la entrada del usuario mientras que otro hilo
ejecuta las rdenes y actualiza la hoja de clculo. Esta medida suele
aumentar la velocidad que se percibe en la aplicacin, permitiendo que el
programa pida la orden siguiente antes de terminar la anterior.
Procesamiento asncrono
Los elementos asncronos de un programa se pueden implementar como
hilos. Un ejemplo es como los softwares de procesamiento de texto guardan
archivos temporales cuando se est trabajando en dicho programa. Se crea
un hilo que tiene como funcin guardar una copia de respaldo mientras se
contina con la operacin de escritura por el usuario sin interferir en la
misma.
Aceleracin de la ejecucin
Se pueden ejecutar, por ejemplo, un lote mientras otro hilo lee el lote
siguiente de un dispositivo.
Estructuracin modular de los programas
Puede ser un mecanismo eficiente para un programa que ejecuta una gran
variedad de actividades, teniendo las mismas bien separadas mediante a
hilos que realizan cada una de ellas.
Implementaciones
Hay dos grandes categoras en la implementacin de hilos:
Hilos a nivel de usuario
Hilos a nivel de Kernel
Tambin conocidos como ULT (User Level Thread) y KLT (Kernel Level
Thread)
Hilos a nivel de usuario (ULT)
En una aplicacin ULT pura, todo el trabajo de gestin de hilos lo realiza la
aplicacin y el ncleo o kernel no es consciente de la existencia de hilos. Es
posible programar una aplicacin como multihilo mediante una biblioteca de
hilos. La misma contiene el cdigo para crear y destruir hilos, intercambiar
mensajes y datos entre hilos, para planificar la ejecucin de hilos y para
salvar y restaurar el contexto de los hilos.
Todas las operaciones descritas se llevan a cabo en el espacio de usuario de
un mismo proceso. El kernel continua planificando el proceso como una
unidad y asignndole un nico estado (Listo, bloqueado, etc.).
Ventajas de los ULT
El intercambio de los hilos no necesita los privilegios del modo kernel,
por que todas las estructuras de datos estn en el espacio de direcciones de
usuario de un mismo proceso. Por lo tanto, el proceso no debe cambiar a
modo kernel para gestionar hilos. Se evita la sobrecarga de cambio de modo
y con esto el sobrecoste o overhead.

Se puede realizar una planificacin especfica. Dependiendo de que

aplicacin sea, se puede decidir por una u otra planificacin segn sus
ventajas.

Los ULT pueden ejecutar en cualquier sistema operativo. La biblioteca

de hilos es un conjunto compartido.
Desventajas de los ULT

En la mayora de los sistemas operativos las llamadas al sistema

(System calls) son bloqueantes. Cuando un hilo realiza una llamada al
sistema, se bloquea el mismo y tambin el resto de los hilos del proceso.

En una estrategia ULT pura, una aplicacin multihilo no puede

aprovechar las ventajas de los multiprocesadores. El ncleo asigna un solo
proceso a un solo procesador, ya que como el ncleo no interviene, ve al
conjunto de hilos como un solo proceso.

Una solucin al bloqueo mediante a llamadas al sistema es usando la

tcnica de jacketing, que es convertir una llamada bloqueante en no
bloqueante.
Hilos a nivel de ncleo (KLT)
En una aplicacin KLT pura, todo el trabajo de gestin de hilos lo realiza el
kernel. En el rea de la aplicacin no hay cdigo de gestin de hilos,
nicamente un API (interfaz de programas de aplicacin) para la gestin de
hilos en el ncleo. Windows 2000, Linux y OS/2 utilizan este mtodo. Linux
utiliza un mtodo muy particular en que no hace diferencia entre procesos e
hilos, para linux si varios procesos creados con la llamada al sistema "clone"
comparten el mismo espacio de direcciones virtuales el sistema operativo
los trata como hilos y lgicamente son manejados por el kernel.
Ventajas de los KLT
El kernel puede planificar simultneamente mltiples hilos del mismo
proceso en mltiples procesadores.

Si se bloquea un hilo, puede planificar otro del mismo proceso.

Las propias funciones del kernel pueden ser multihilo

Desventajas de los KLT

El paso de control de un hilo a otro precisa de un cambio de modo.
Combinaciones ULT y KLT
Algunos sistemas operativos ofrecen la combinacin de ULT y KLT, como
Solaris.
La creacin de hilos, as como la mayor parte de la planificacin y
sincronizacin de los hilos de una aplicacin se realiza por completo en el
espacio de usuario. Los mltiples ULT de una sola aplicacin se asocian con
varios KLT. El programador puede ajustar el nmero de KLT para cada
aplicacin y mquina para obtener el mejor resultado global.
Sincronizacin y Comunicacin entre procesos
La comunicacin entre procesos: necesaria si se desea que varios procesos
puedan colaborar para realizar una misma tarea. Sincronizacin ===
funcionamiento coordinado en la resolucin de una tarea encomendada.
El SO ofrece mecanismos bsicos de comunicacin, que permiten transferir
cadenas de bytes. Deben ser los procesos que se comunican quienes
interpreten el significado de las cadenas transferidas para su labor
coordinada.
Los mecanismos de comunicacin y sincronizacin son dinmicos. Es decir,
cuando se necesita un mecanismo de este estilo, se crea, usa y destruye, de
forma que no se establezca de forma definitiva ningn mecanismo de
comunicacin, ya que ellos podran producir efectos indeseados. Es decir, la
comunicacin es algo puntual.

Los servicios bsicos de comunicacin son:

a.
crear: el proceso solicita la creacin del mecanismo
b.
c.
d.

enviar o escribir: el proceso emisor enva informacin al proceso

receptor
recibir o leer: el proceso receptor recibe informacin
destruir: el proceso solicita la destruccin del mecanismo de
comunicacin

La comunicacin puede ser sincrona y asncrona:

a.
sncrona: los dos procesos han de ejecutar servicios de forma
simultnea. El emisor ha de ejecutar el servicio enviar mientras el
receptor ejecuta recibir.
b.

asncrona: el emisor hace el envo y prosigue su ejecucin. El SO

ofrece un almacenamiento intermedio para guardar la informacin
enviada, hasta que el receptor la solicite.

Esquema de Sincronizacin Sincrona

En un sistema operativo multiprogramado los procesos compiten por el

acceso a los recursos compartidos o cooperan dentro de una misma
aplicacin para comunicar informacin. Ambas situaciones son tratadas por
el sistema operativo mediante mecanismos de sincronizacin que permiten
el acceso exclusivo de forma coordinada a los recursos y a los elementos de
comunicacin compartidos. Segn el modelo de sistema operativo descrito
anteriormente, basado en colas de procesos y transiciones de estados, los
procesos abandonan la CPU para pasar a estado bloqueado cuando
requieren el acceso a algn dispositivo, generalmente en una operacin de
E/S, pasando a estado preparado cuando la operacin ha concluido y
eventualmente volver a ejecucin. La gestin de estos cambios de estado,
es decir, los cambios de contexto, es un ejemplo de seccin crtica de
cdigo dentro del sistema operativo que debe ser ejecutada por ste en
exclusin mutua. Otros ejemplos de cdigo que debe protegerse como
seccin crtica incluyen la programacin de los dispositivos de E/S y el
acceso a estructuras de datos y buffers compartidos.
Dentro del dentro del ncleo del sistema operativo, el espacio de
direcciones es nico, por lo que la comunicacin se resuelve mediante el
uso de variables de memoria compartida. Como contrapartida a la agilidad

de este esquema, es necesario utilizar mecanismos explcitos de

sincronizacin para garantizar acceso exclusivo a las variables compartidas.
Si se definen buffers o colas compartidas a las que se proporciona acceso
exclusivo, se pueden utilizar esquemas de comunicacin ms elaborados,
como es el caso del productor-consumidor. El esquema cliente-servidor es
un caso particular del productor-consumidor donde los clientes producen
peticiones que son consumidas por el servidor de un determinado recurso.
Un sistema operativo con estructura cliente-servidor resulta atractivo por la
claridad de su diseo. Cuando los procesos que se comunican mediante
estos esquemas no comparten el espacio de direcciones, lo que sucede en
particular en sistemas basados en micro ncleo, se requieren primitivas de
comunicacin por paso de mensajes, que, al gestionar implcitamente la
sincronizacin, simplifican la programacin de la comunicacin.
En los apartados siguientes vamos a tratar el problema de la seccin crtica
y sus soluciones. La seccin crtica no es el nico problema a resolver en un
sistema operativo. Aunque se utilicen esquemas de comunicacin
elaborados, las interacciones en el uso de los recursos pueden conducir a
interbloqueos, problema que se tratar ms adelante.
Seccin crtica
En programacin concurrente, se define como a la porcin de cdigo de un
programa de computador el cual accede a un recurso compartido
(estructura de datos dispositivo) que no debe de ser accedido por mas de
un hilo en ejecucin (thread). La seccin crtica por lo general termina en un
tiempo determinado y el hilo, proceso tarea solo tendr que esperar un
perodo determinado de tiempo para entrar. Se necesita de un mecanismo
de sincronizacin en la entrada y salida de la seccin crtica para asegurar
la utilizacin exclusiva del recurso, por ejemplo un semforo.
El acceso concurrente se controla teniendo cuidado de las variables que se
modifican dentro y fuera de la seccin crtica. La seccin crtica se utiliza por
lo general cuando un programa multihilo actualiza mltiples variables sin un
hilo de ejecucin separado que lleve los cambios conflictivos a esos datos.
Una situacin similar, la seccin crtica puede ser utilizada para asegurarse
de que un recurso compartido, por ejemplo, unaimpresora, puede ser
accedida por un solo proceso a la vez.
La manera en como se implementan las secciones puede variar
dependiendo de los diversos sistemas operativos.
Slo un proceso puede estar en una seccin crtica a la vez.
Modelo de seccin crtica
El modelo de seccin crtica que vamos a utilizar sigue el
siguiente protocolo genrico:
Entrar_SC(esta_SC) /* Solicitud de ejecutar esta_SC */
/* cdigo de esta_SC */
Dejar_SC(esta_SC) /* Otro proceso puede ejecutar esta_SC */
Es decir, cuando un proceso quiere entrar a la seccin crtica:
(1) ejecuta Entrar_SC(), y si la seccin crtica est ocupada el proceso
espera;
(2) ejecuta la seccin crtica;
(3) ejecuta Dejar_SC(), permitiendo que entre uno de los procesos en
espera.
La decisin de qu proceso es el seleccionado para entrar en el paso (3)
puede tener consecuencias importantes, como se comentar ms adelante.
En general, puede asumirse disciplina FIFO.
Un aspecto fundamental es cmo se realiza la espera en Entrar_SC(), lo que
determina el tipo de mecanismo de sincronizacin que se debe utilizar. Esto

depender del tiempo que el proceso deba esperar para entrar a la seccin
crtica. La Figura C muestra un ejemplo de utilizacin de una seccin crtica
para implementar sincronizacin productor-consumidor. Hay que advertir
que este ejemplo slo es vlido para un productor y un consumidor. Con n
productores y m consumidores se produciran condiciones de carrera. Se
propone como ejercicio la modificacin de este cdigo para el caso general.

Figura C. Una implementacin del productor-consumidor (slo

vlido para un productor y un consumidor).
Si se va a esperar durante un tiempo que compense el coste de los cambios
de contexto asociados a bloquear y desbloquear el proceso, la exclusin
mutua se implementa como de largo plazo. La espera por bloqueado resulta
entonces ms eficiente que la espera activa o mucho menos restrictiva que
la inhibicin de interrupciones. Un ejemplo de exclusin mutua de largo
plazo es el acceso a un driver de un dispositivo, como el de disco.
Vamos a abordar a continuacin los mecanismos de sincronizacin en los
sistemas operativos, tanto los de corto plazo, que se basan en la espera por
ocupado (incluyendo inhibicin de interrupciones y cerrojos de espera
activa), como los de espera por bloqueado (primitivas de dormir/despertar y
semforos), adems de un mecanismo de comunicacin de alto nivel
semntico como es el paso de mensajes. Existen otros mecanismos, como
regiones crticas y monitores, que no vamos a desarrollar en la
siguiente investigacin.
Antes de ello es preciso revisar las propiedades que deben cumplir estos
mecanismos.
Propiedades del acceso exclusivo a secciones crticas:
Como criterios de validez de un mecanismo de sincronizacin nos
referiremos al cumplimiento de las siguientes condiciones enunciadas por
Dijkstra para el acceso exclusivo a una seccin crtica.
a.
SC.
b.
Exclusin mutua. No puede haber ms de un proceso
simultneamente en la
c.

No interbloqueo. Ningn proceso fuera de la SC puede impedir que

otro entre a la SC.

d.

No inanicin. Un proceso no puede esperar por tiempo indefinido

para entrar a la SC.

e.

Independencia del hardware. No se pueden hacer suposiciones

acerca del nmero de procesadores o de la velocidad relativa de los
procesos.

Suposicin inicial adicional: las instrucciones del Lenguaje Mquina son

atmicas y se ejecutan secuencialmente.
Adems, existen otros criterios que determinan la calidad del mecanismo y
que fundamentalmente se refieren a su rendimiento, como son
la productividad (nmero de operaciones de sincronizacin por unidad de
tiempo que el mecanismo es capaz de soportar) y el tratamiento equitativo
entre los procesos (por ejemplo, siguiendo una poltica FIFO para entrar a la
seccin crtica).
Espera por ocupado
La espera por ocupado engloba una serie de mecanismos de sincronizacin
que proporcionan acceso a secciones crticas de corto plazo. El ms sencillo
y ms utilizado en los sistemas operativos clsicos es la inhibicin de
interrupciones. En multiprocesadores es necesario utilizar cerrojos de espera
activa.
Inhibicin de interrupciones
Las secciones crticas protegidas por interrupciones se especifican de la
siguiente forma:
s= inhibir() /* Inhibe interrupciones */
/* Seccin crtica */
desinhibir(s) /* Restaura estado anterior de interrupciones */
Este mecanismo lleva asociadas importantes restricciones. No cumple la
condicin de independencia del hardware, ya que en un multiprocesador
slo se inhiben las interrupciones en el procesador que ejecuta la inhibicin,
restringindose por tanto a las implementaciones monoprocesador. Por otra
parte, en monoprocesadores, un proceso que utilizase la inhibicin de
interrupciones como forma de acceso exclusivo a secciones crticas de
duracin arbitrariamente larga impedira a los dems procesos ejecutar
cdigo alguno, an ajeno a la seccin crtica. En los sistemas UNIX clsicos
todo el cdigo de las llamadas al sistema se ejecuta como seccin crtica, lo
que hace a estos sistemas poco adecuados para aplicaciones de tiempo
real, ya que es difcil acotar los tiempos de respuesta.

Leer ms: http://www.monografias.com/trabajos51/sincrocomunicacion/sincro-comunicacion2.shtml#ixzz3QKbbtXAn