Clase 04: Procesos

PROCESOS Y THREADS
El concepto de proceso se origina en el campo de los sistemas operativos, donde comnmente se define
como un programa en ejecucin.
Un thread se puede considerar como la agrupacin de un trozo de programa junto con el
conjunto de registros del procesador que utiliza y una pila de mquina. El conjunto de los registros y de
la pila de cada thread se denomina contexto.
Desde la perspectiva de un sistema operativo, la administracin y programacin temporal de los
procesos es tal vez el aspecto ms crtico. Sin embargo, en los sistemas distribuidos hay otras cuestiones
que son igualmente importantes.
Por ejemplo, para organizar eficientemente sistemas cliente-servidor, frecuentemente resulta
conveniente utilizar tcnicas multithreading (multihilo). La principal contribucin de los threads (hilos)
en los sistemas operativos es que permiten que clientes y servidores sean construidos de tal manera que
la comunicacin y el procesamiento local puedan traslaparse en el tiempo, permitiendo con ello
mayores niveles de desempeo.
Aunque los procesos constituyen el bloque bsico en la implementacin de sistemas distribuidos, la
prctica muestra que el plantear la granularidad (divisin) de un sistema distribuido en diferentes
procesos, tal como lo establecen los sistemas operativos en los que se construyen los sistemas
distribuidos, no es suficiente. Resulta que plantear una granularidad ms fina en la forma de threads
mltiples de control por proceso, hace ms fcil desarrollar aplicaciones distribuidas y obtener un mejor
desempeo.
4.1 Introduccin a Procesos y Threads
Para entender el papel que juegan los threads en los sistemas distribuidos, es importante entender qu
es un proceso, y como se relacionan los procesos y los threads. Al ejecutar programas, el sistema
operativo crea un cierto nmero de procesos virtuales, cada uno para correr un programa diferente. Con
la finalidad de mantener un control y seguimiento de todos estos procesadores virtuales, el sistema
operativo usa una tabla de procesos, la cual contiene entradas para almacenar los valores de los
registros del CPU, mapas de memoria, archivos abiertos, informacin del proceso, privilegios, etc. Un
proceso es frecuentemente definido como un programa en ejecucin, es decir, un programa que est
siendo ejecutado en uno de los procesadores virtuales del sistema operativo. Un asunto importante es
que el sistema operativo tiene mucho cuidado de asegurar que procesos independientes no puedan de
forma maliciosa o inadvertida afectar el comportamiento adecuado de los dems. En pocas palabras,
procesos mltiples puedan compartir concurrentemente el mismo CPU y otros recursos de hardware de
forma transparente. Usualmente, el sistema operativo requiere de hardware que permita esta
separacin.
Esta transparencia de concurrencia tiene un alto costo. Por ejemplo, cada vez que un proceso es
creado, el sistema operativo debe crear un espacio de direcciones independiente y completo. La
Clase 04: Procesos
asignacin de este espacio de memoria puede requerir de la inicializacin de segmentos de memoria,
por ejemplo, poner en ceros todo el segmento de datos, copiar el programa asociado en el segmento de
texto (instrucciones), y preparar un segmento de stack para datos temporales. Tambin resulta costoso
el que el CPU realice un switch (cambio) de contexto (valores de registros, contador de programa,
apuntador de stack, etc.) para cambiar de la ejecucin de un proceso a otro. Aparte de grabar el
contexto del CPU, el sistema operativo debe modificar los registros de una Unidad de Administracin de
Memoria (MMU) e invalidar cachs de traduccin de direcciones, tales como el buffer de traduccin de
direcciones virtuales (TLB Translation Lookaside Buffer). Adems, si el sistema operativo brinda
soporte a ms procesos de los que pueden sostenerse simultneamente en la memoria principal, ste
debe hacer un swap (cambio) de procesos entre la memoria principal y el disco antes de que se realice el
switch de contexto.
Un proceso sencillo puede contener varios programas ejecutables conocidos como threads
(hilos), que trabajan de manera conjunta como un todo coherente, cooperando entre s (ver Figura 4.1).
En un programa o proceso, por ejemplo, un thread podra manejar seales de error, otro podr enviar un
mensaje al usuario sobre ese error, mientras que un tercer thread podra ejecutar la tarea principal del
programa.


Figura 4.1. Diferentes esquemas de uso de threads en procesos.

Un thread resulta de la divisin de un programa en dos o ms tareas que pueden correr
concurrentemente. Mltiples threads pueden existir dentro de un mismo proceso y, por lo tanto,
comparten entre s los mismos recursos, tales como el espacio de memoria del proceso al que
pertenecen. Las diferencias principales entre procesos y threads son las siguientes:
Los procesos son tpicamente independientes, mientras los threads existen como subconjuntos
de los procesos.
Clase 04: Procesos
Los procesos contienen una cantidad considerable de informacin de estatus o contexto,
mientras los threads mltiples dentro de un proceso comparte este estatus al igual que la
memoria y otros recursos (ver Figura 4.2).
Los procesos tienen espacios de direcciones separados entre s, son independientes. Los threads
comparten el mismo espacio de direcciones (ver Figura 4.2).
Los procesos interactan entre s solo mediante mecanismos de comunicacin interproceso
(IPC), lo cual se explicar con mayor detalle ms adelante.
El cambio de contexto (context switching) entre threads en el mismo proceso es tpicamente
ms rpido que el cambio de contexto entre procesos. Al igual que un proceso, un thread
ejecuta su propia parte de cdigo, independientemente de los otros threads. Sin embargo, en
contraste con un proceso, el thread no intenta obtener un alto grado de transparencia de
concurrencia si esto implica una degradacin de desempeo. Por lo tanto, un sistema de threads
generalmente mantiene solo el mnimo de informacin para que un CPU pueda ser compartido
por varios threads. En particular, un contexto de thread comnmente consiste simplemente de
un contexto de CPU y de informacin para la administracin de threads.


Figura 4.2. Informacin de los contextos de un proceso y un thread (hilo).

Hay dos implicaciones importantes del uso de threads al momento de implementar una
aplicacin. Primero que todo, el desempeo de una aplicacin multithread difcilmente es peor que su
contraparte de thread sencillo (proceso simple). De hecho, en muchos casos, el uso de thread mltiples
permite obtener mejores niveles de desempeo. Segundo, ya que los threads no son protegidos
automticamente unos de otros como en el caso de los procesos, el desarrollo de aplicaciones
multithread requiere de un esfuerzo intelectual adicional.
4.2 Niveles de Threads
Existen dos categoras bsicas de threads:
Clase 04: Procesos
Threads de Nivel-Usuario: implementados generalmente por medio de libreras de threads.
Threads de Nivel-Kernel: implementados mediante llamadas a sistema.
De la combinacin de ambas categoras se deriva una tercera conocida como
Threads de Nivel-Hibrido o Combinados.
La Figura 4.3 muestra el esquema de cada uno de estas tres categoras de threads.


Figura 4.3. (a) Threads Nivel-Usuario, (b) Threads Nivel-Kernel, (c) Threads Hibridos o Combinados.

Thread Nivel-Usuario (ULT)
En este nivel, el Kernel no tiene la nocin de la existencia de los threads. Toda la administracin
de los threads es realizada por la aplicacin usando una librera de threads. El cambio de contexto de
threads no requiere de privilegios para el modo kernel (no hay cambio de modo) y la calendarizacin o
programacin en tiempo depende especficamente de la aplicacin.
Actividad del Kernel en threads de nivel-usuario:
El Kernel no sabe de la actividad de los threads pero an administra la actividad de procesos.
Cuando un thread hace una llamada a sistema (system call), el proceso por completo ser
bloqueado (*), pero para la librera de threads ese thread an est corriendo (en estado de
correr - running).
Los estados de los threads son independientes de los estados de los procesos.
Clase 04: Procesos
NOTA (*): Recuerde que un proceso puede estar en distintos estados dentro de su vida (mientras existe). Uno de estos estados
es el de bloqueado, lo cual significa que se encuentra en espera de que ocurra un evento especfico para poder continuar su
procesamiento.

Ventajas:
El cambio de contexto de los threads no involucra al kernel, no se requiere cambio de modo.
La calendarizacin puede ser especfica a la aplicacin, se puede seleccionar el mejor algoritmo.
Los threads nivel-usuario pueden correr en cualquier sistema operativo, solo se requiere una
librera de threads.
Desventajas:
La mayora de las llamadas a sistema son de bloqueo y el Kernel bloquea a los procesos,
entonces todos los threads dentro del proceso tambin sern bloqueados.
El Kernel solo puede asignar procesos a procesadores, por lo que dos threads dentro del mismo
proceso no pueden correr simultneamente en dos procesadores.
Thread Nivel-Kernel (KLT)
En este nivel, toda la administracin de los threads se efecta en el Kernel, no se usa librera de
threads pero s debe existir llamadas a sistema dirigidas a los servicios de threads que provee el Kernel.
El Kernel mantiene la informacin de contexto tanto de procesos como de threads, y el cambio de
contexto de threads requiere que la calendarizacin que establece el Kernel sea basada en threads.
Ventajas:
El Kernel puede calendarizar simultneamente varios threads del mismo proceso en varios
procesadores, el bloqueo se efecta a nivel thread y no a nivel proceso.
Las rutinas del Kernel pueden ser multithread.
Desventajas:
El cambio de contexto entre threads del mismo proceso involucra al Kernel. Si se tienen dos
cambios de modo por cambio de contexto de switch, se aletarga la respuesta del sistema.
Thread Hibrido o Combinado
La idea es combinar lo mejor de cada categora anterior.
El sistema operativo solaris, UNIX de Sun Microsystems, es un buen ejemplo de sistema
operativo que da soporte a threads hibridos.
La creacin de threads tiene lugar en el espacio de usuario (modo de usuario).
Las tareas de calendarizacin y sincronizacin de threads se realiza en el espacio de usuario.
Clase 04: Procesos
El programador puede ajustar el nmero de KLTs.
El Proceso incluye el espacio de direcciones de usuario, stack y bloqueo de control de proceso.
Los ULTs (libreras de threads) invisibles al sistema operativo son la interfaz para el paralelismo
de la aplicacin.
Los KLTs son la unidad que puede ser despachada (asignada) a un procesador.
Cada proceso de peso ligero (LWP Lightweight Process) (**) soporta uno o ms ULTs y es
mapeado a solo un KLT.
NOTA (**): Un proceso de peso ligero (LWP) es un tipo especfico de thread nivel-kernel (KLT) que comparte el mismo estado e
informacin.Un LWP es un medio para implementar el multitasking. Un LWP corre arriba de un thread nivel-kernel sencillo y
comparte su espacio de direcciones y recursos de sistema con otros LWPs que pertenecen al mismo proceso. El LWP puede
generar mltiples threads de nivel-usuario (ULTs), permitiendo con ello el multitasking a nivel usuario, lo cual puede traer
algunos benecifios de desempeo.

La Figura 4.4 muestra lo anteriormente dicho.

Figura 4.4. Implementacin de threads en el sistema operativo Solaris de Sun Microsystems.

4.3 Uso de procesos y threads en sistemas no distribuidos
Clase 04: Procesos
Las aplicaciones grandes son frecuentemente desarrolladas como una coleccin de programas
que colaboran entre s, y cada uno de los cuales es ejecutado por un proceso separado. Este mtodo es
tpico en un ambiente UNIX. La cooperacin entre procesos es comnmente implementada por medio
de mecanismos de comunicacin interproceso (IPC). En los sistemas UNIX, estos mecanismos
tpicamente incluyen pipas, filas de mensaje, segmentos de memoria compartida, sockets, RPCs, etc.
Una de las principales desventajas de todos los mecanismos IPC es que la comunicacin requiere
frecuentemente de una cantidad considerable de cambios de contexto, los cuales se dan en tres puntos
diferentes, tal como se muestra en la Figura 4.5.


Figura 4.5. Cambio de contexto (context switching) como resultado de un IPC.

Ya que un IPC requiere de la intervencin del kernel, un proceso generalmente tiene que cambiar de
modo de usuario a modo de kernel, lo cual se muestra en el punto S1 de la figura anterior. Esto requiere
cambiar el mapa de memoria en el MMU, y tambin desalojar el TLB. Dentro del kernel, se efecta un
cambio de contexto de proceso (punto S2 en la grfica anterior, caso ilustrado tambin en la Figura
4.6a), despus de lo cual el otro proceso puede se activado al cambiar de modo kernel al modo usuario,
de nueva cuenta (punto S3). El ltimo cambio requiere una vez ms el cambiar el mapa del MMU y
desalojar el TLB.
En lugar de usar procesos, una aplicacin puede ser construida de tal manera que partes
diferentes de la misma sean ejecutadas por threads separados. La comunicacin entre estas partes se
implementa completamente con el uso de datos compartidos. El cambio de contexto de threads
(threads switching) puede hacerse frecuentemente en el espacio de usuario, aunque el kernel est al
tanto de los threads y los controle y programe en el tiempo (ver Figura 4.6). El resultado puede ser una
mejora dramtica en el desempeo.
Clase 04: Procesos
Una ventaja de una granulacin ms fina, mediante la divisin de la aplicacin en mltiples
threads (multithreading) es que hace posible el explotar el paralelismo cuando se ejecuta un programa
en un ambiente multitasking, y, an ms, en una mquina multiprocesador (existen sistemas operativos
que dan soporte a ambos ambientes, multitasking y multiprocesador a la vez). En el caso multitasking, el
tiempo de CPU es dividido entre threads y no entre procesos (ver Figura 4.6b). En el caso del sistema
multiprocesador, cada thread es asignado a un CPU diferente mientras que los datos compartidos son
almacenados en memoria principal compartida (ver Figura 4.6c). Cuando el diseo es apropiado, tal
paralelismo puede ser transparente: el proceso correr igualmente bien en un sistema uniprocesador,
aunque un poco ms lento. El uso de multithreading para la implementacin de paralelismo se ha vuelto
cada vez ms importante y extendido, gracias a la disponibilidad de estaciones de trabajo
multiprocesador cuyos precios se han reducido significativamente. Estos sistemas de cmputo son
tpicamente usados para correr servidores en aplicaciones cliente-servidor.


Figura 4.6. (a) Multitasking basado en procesos (procesos con un solo thread), (b) Multitasking basado
en threads (procesos con multithreads), (c) Procesos con multithreads en un ambiente multiprocesador.

Finalmente, hay una razn de la ingeniera de software para usar threads: muchas aplicaciones
son ms sencillas de estructurar como una coleccin de threads cooperativos. Por ejemplo, en el caso de
Clase 04: Procesos
un procesador de palabras (ver Figura 4.7), se pueden usar threads separados para manejar la entrada
de usuario en el teclado, revisar la ortografa y gramtica, grabar el documento en disco, etc.

Figura 4.7. Esquema de un procesador de palabras dividido en threads.

4.4 Uso de threads en sistemas distribuidos