PDF de programación - Capitulo. Procesos vs Hilos

CAPÍTULO 2. PROCESOS VS. HILOS



El objetivo de este capítulo es el de discutir con un poco más de profundidad
todo lo relacionado con el concepto de proceso que sea relevante para el
estudio de la programación concurrente. En esta discusión aparecerá un nuevo
concepto que es el de hilo o hebra1 y que resulta fundamental para entender
cómo es la programación concurrente en Java.

En primer lugar veremos el ciclo de vida de un proceso y las nociones de
planificación de procesos y cambio de contexto. Posteriormente, se verá la
disposición en memoria de las estructuras de datos relacionadas con un
proceso. Por último nos adentraremos en el mundo de los hilos y su relación
con los procesos y, particularmente, nos centraremos en el estudio de la
gestión de hilos en Java.
2.1 Procesos
2.1.1 Ciclo de vida de un proceso
En la Figura 1 puede apreciarse el ciclo de vida que suele seguir un proceso.
Este ciclo de vida es prácticamente estándar en todos los SSOO.



Creado

Listo

es su turno

fin de turno o abandono
voluntario

ocurre suceso

Bloqueado

Ejecución

Terminado

espera suceso



Figura 1 Estados de un proceso.


En un principio, un proceso no existe. En algún momento es creado. La
forma de crearlo variará en función del lenguaje que se esté utilizando. Una vez
creado el proceso, éste pasa al estado denominado Listo. Este estado significa
que el proceso está en condiciones de hacer uso de la CPU en cuanto se le dé
la oportunidad. El encargado de darle la oportunidad de usar la CPU es el
denominado planificador de procesos o scheduler, que suele formar parte
del SO. Como lo normal es que haya más procesos que procesadores, no
todos los procesos que pueden hacer uso de la CPU en un momento
determinado pueden hacerlo realmente. Esos procesos permanecen en el



1 Suelen ser las traducciones más aceptadas del término inglés thread. A lo largo de este libro
utilizaremos el término hilo. Usaremos Thread cuando hagamos referencia a la clase con ese nombre en
Java.
M.E Carmen Cerón G. Programación Concurrente BUAP

23



estado listo hasta que el planificador decide darles tiempo de CPU. Cuando el
planificador decide dar tiempo de CPU a un proceso, éste pasa al estado de
Ejecución.


Como puede comprobarse en la Figura 1, un proceso también puede pasar
de Ejecución a Listo. Esta decisión la toma el planificador. El planificador sigue
algún tipo de política de planificación para asignar la CPU a los distintos
procesos. Una forma bastante justa y extendida de hacerlo es mediante la
asignación de rodajas de tiempo a cada uno de los procesos, de tal forma que
cuando un proceso cumple su tiempo de permanencia en el procesador, éste
es desalojado y pasado al estado listo. En este estado esperará una nueva
oportunidad para pasar a Ejecución. También es posible que un proceso
abandone voluntariamente la CPU y pase de esta forma al estado listo.


También en la Figura 1 puede apreciarse la presencia del estado Bloqueado.
Un proceso puede pasar de Ejecución a Bloqueado cuando ha de esperar
porque ocurra un determinado evento o suceso. Ejemplos de eventos pueden
ser la espera por la terminación de una operación de Entrada/Salida, la espera
por la finalización de una tarea por parte de otro proceso, un bloqueo voluntario
durante un cierto período de tiempo, etc. Una vez que ocurre el evento por el
que se está esperando, el proceso pasa al estado Listo. Al acto de cambiar un
proceso de estado se le denomina cambio de contexto.

2.1.2 Disposición en memoria de un proceso
En un Sistema Operativo tradicional, la memoria suele estar dividida en dos
partes: un espacio de usuario donde suele encontrarse la mayoría de la
información relativa a los procesos de usuario y un espacio del núcleo donde
reside el código y las estructuras de datos propios del SO.



Espacio del usuario

Espacio del núcleo

pila y puntero de pila

proceso

código del
programa de
usuario y contador
de programa
datos globales

bloque de control del proceso

núcleo

datos del SO

código del SO



Figura 2 Mapa de memoria de un proceso para un SO multitarea.


Cuando estamos ante un SO multitarea, la información relativa a un proceso
suele estar dividida entre los dos espacios (Figura 2). En el espacio de usuario
se encuentra información propia del proceso tales como el código del proceso,
el contador de programa, sus variables, su pila y su puntero de pila. Sin
embargo, el SO necesita tener información del estado de los procesos para
poder realizar apropiadamente los cambios de contexto. Esta información, que
suele conocerse con el nombre de bloque de control del proceso (PCB),

M.E Carmen Cerón G. Programación Concurrente BUAP



24



suele residir en el espacio del núcleo. En la Figura 3 puede verse la estructura
de un proceso en el SO Unix. La información contenida en la estructura del
proceso puede variar de un SO a otro, pero sustancialmente suele ser la
misma.



ID del proceso

UID, GID, EUID, ...

Tabla de señales

Descriptores de ficheros

Mapa de memoria

prioridad

registros

pila

...

Estado de la CPU



Figura 3 Estructura tradicional de un proceso en UNIX.



Cuando tenemos más de un proceso, se tiene algo como lo representado en
la Figura 4. En el espacio del núcleo estará el planificador de procesos que
será el encargado de decidir cuándo hacer los cambios de contexto. Cuando se
hace el cambio de contexto hay que recuperar la estructura del proceso que se
quiere poner en el estado Ejecución y actualizar convenientemente los registros
del procesador para que el nuevo proceso tome el control del mismo. Los
cambios de contexto son costosos desde el punto de vista del tiempo de
ejecución pues consumen un tiempo considerable.

Cada proceso de los representados en la figura tiene su propio contador de
programa, su propia pila, etc. Cada proceso suele tener un solo hilo de
ejecución; se dice entonces que son monohilo.

espacio del usuario

espacio del núcleo



proceso 1



proceso 2



proceso 3

Figura 4 Varios procesos en un SO multitarea.



2.2 Hilos
Aunque el concepto de hilo lleva existiendo varias décadas, no ha sido hasta
los 90 cuando ha alcanzado una cierta mayoría de edad. Mientras que a
comienzos de los 90 el uso de hilos se circunscribía a la investigación en
universidades y al desarrollo en sectores industriales específicos, a finales de
los 90 y en el nuevo milenio, el uso de hilos está ampliamente extendido. La

M.E Carmen Cerón G. Programación Concurrente BUAP



25



incorporación del concepto de hilo al lenguaje Java ha supuesto un empuje
definitivo a su uso.

Pero, ¿qué es un hilo?. De la misma manera que un Sistema Operativo
puede ejecutar varios procesos al mismo tiempo bien sea por concurrencia o
paralelismo, dentro de un proceso puede haber varios hilos de ejecución. Por
tanto, un hilo puede definirse como cada secuencia de control dentro de
un proceso que ejecuta sus instrucciones de forma independiente.

En la Figura 5 puede verse cómo sobre el hardware subyacente (una o
varias CPU’s) se sitúa el Sistema Operativo. Sobre éste se sitúan los procesos
(Pi) que pueden ejecutarse concurrentemente y dentro de estos se ejecutan los
hilos (hj) que también se pueden ejecutar de forma concurrente dentro del
proceso. Es decir, tenemos concurrencia a dos niveles, una entre procesos y
otra entre hilos de un mismo proceso. Si por ejemplo tenemos dos
procesadores, se podrían estar ejecutando al mismo tiempo el hilo 1 del
proceso 1 y el hilo 2 del proceso 3. Otra posibilidad podría ser el hilo 1 y el hilo
2 del proceso 1.



procesos

hilos
...

espacio de usuario

espacio del
núcleo

hilos del sistema

t1 h2
PCB

P1

h1 h2 h3 h4

PCB

P2

h1 h2 h3

PCB

P3

Sistema Operativo

CPU o conjunto de CPU’s



Figura 5 Concurrencia a dos niveles: procesos e hilos.


Los procesos son entidades pesadas. La estructura del proceso está en la
parte del núcleo y, cada vez que el proceso quiere acceder a ella, tiene que
hacer algún tipo de llamada al sistema, consumiendo tiempo extra de
procesador. Por otra parte, los cambios de contexto entre procesos son
costosos en cuanto a tiempo de computación se refiere. Por el contrario, la
estructura de los hilos reside en el espacio de usuario, con lo que un hilo es
una entidad ligera. Los hilos comparten la información del proceso (código,
datos, etc). Si un hilo modifica una variable del proceso, el resto de hilos verán
esa modificación cuando accedan a esa variable. Los cambios de contexto
entre hilos consumen poco tiempo de procesador, de ahí su éxito.

Podemos hablar de dos niveles de hilos: aquellos que nosotros usaremos
para programar y que pueden crearse desde lenguajes de programación como
Java y aquellos otros hilos del propio SO que sirven para dar soporte a
nuestros hilos de usuario y que son los hilos del sistema según la Figura 5.
Cuando nosotros programamos con hilos, hacemos uso de un API (Application

M.E Carmen Cerón G. Programación Concurrente BUAP



26



Program Interface) proporcionado por el lenguaje, el SO o un tercero mediante
una librería extern