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