Unidad 3 Procesos y Procesadores en Sistemas Distribuidos.
3.1 Procesos y procesadores, conceptos básicos.
PROCESO:
Un proceso es un programa en ejecución, la cual debe proceder de manera secuencial. Un proceso además del código del programa, incluye la actividad actual, representada por el valor del contador de programa, y el valor de los registros de la CPU. Generalmente también incluye al stack del proceso, que contiene datos temporales, y una sección de datos que contiene variables globales.
Un programa, es una entidad pasiva, como un archivo en disco, mientras que un proceso es una entidad activa.
Aunque podría haber dos procesos asociados al mismo programa, de todas maneras se consideran como dos secuencias de ejecución distintas.
Un proceso es un concepto manejado por el sistema operativo que consiste en el conjunto formado por:
Esta definición varía ligeramente en el caso de sistemas operativos multihilo, donde un proceso consta de uno o más hilos, la memoria de trabajo (compartida por todos los hilos) y la información de planificación. Cada hilo consta de instrucciones y estado de ejecución.
Los procesos son creados y destruidos por el sistema operativo, así como también este se debe hacer cargo de la comunicación entre procesos, pero lo hace a petición de otros procesos. El mecanismo por el cual un proceso crea otro proceso se denomina bifurcación (fork). Los nuevos procesos pueden ser independientes y no compartir el espacio de memoria con el proceso que los ha creado o ser creados en el mismo espacio de memoria.
En los sistemas operativos multihilo es posible crear tanto hilos como procesos. La diferencia estriba en que un proceso solamente puede crear hilos para sí mismo y en que dichos hilos comparten toda la memoria reservada para el proceso.
El principal trabajo del procesador es ejecutar las instrucciones de máquina que se encuentran en memoria principal. Estas instrucciones se encuentran en forma de programas. Para que un programa pueda ser ejecutado, el sistema operativo crea un nuevo proceso, y el procesador ejecuta una tras otra las instrucciones del mismo. En un entorno de multiprogramación, el procesador intercalará la ejecución de instrucciones de varios programas que se encuentran en memoria. El sistema operativo es el responsable de determinar las pautas de intercalado y asignación de recursos a cada proceso.
Se trata de la utilización de dos archivos, un objeto ejecutable y una biblioteca del sistema, que después se colocan en la imagen del proceso dentro de la memoria RAM y posteriormente también se dan de alta dentro de la tabla de procesos, Bloque de control del proceso.
El modelo de estados más simple es el de dos estados. En este modelo, un proceso puede estar ejecutándose o no. Cuando se crea un nuevo proceso, se pone en estado de No ejecución. En algún momento el proceso que se está ejecutando pasará al estado No ejecución y otro proceso se elegirá de la lista de procesos listos para ejecutar para ponerlo en estado Ejecución. De esta explicación se desprende que es necesario que el sistema operativo pueda seguirle la pista a los procesos, conociendo su estado y el lugar que ocupa en memoria. Además los procesos que no se están ejecutando deben guardarse en algún tipo de cola mientras esperan su turno para ejecutar.
El modelo anterior de 2 estados funcionaría bien con una cola FIFO y planificación por turno rotatorio para los procesos que no están en ejecución, si los procesos estuvieran siempre listos para ejecutar. En la realidad, los procesos utilizan datos para operar con ellos, y puede suceder que no se encuentren listos, o que se deba esperar algún suceso antes de continuar, como una operación de Entrada/Salida. Es por esto que se necesita un estado donde los procesos permanezcan esperando la realización de la operación de Entrada Salida por parte del Sistema Operativo hasta que puedan proseguir. Se divide entonces al estado No ejecución en dos estados: Listo y Espera. Se agregan además un estado Nuevo y otro Terminado.
Los cinco estados de este diagrama son los siguientes según Osëliyo:
Los nuevos estados Nuevo y Terminado son útiles para la gestión de procesos. En este modelo los estados Espera y Listo tienen ambos colas de espera. Cuando un nuevo proceso es admitido por el sistema operativo, se sitúa en la cola de listos. A falta de un esquema de prioridades ésta puede ser una cola FIFO. Cuando se da un suceso se pasan a la cola de listos los procesos que esperaban por ese suceso.
Si existe un esquema con diferentes niveles de prioridad de procesos es conveniente mantener varias colas de procesos listos, una para cada nivel de prioridad, lo que ayuda a determinar cuál es el proceso que más conviene ejecutar a continuación.
Asimismo, existen varias colas en estado de espera, como mínimo una por cada periférico.
Una de las razones para implementar el estado Espera era poder hacer que los procesos se puedan mantener esperando algún suceso, por ejemplo una Entrada/Salida. Sin embargo, al ser mucho más lentas estas operaciones, puede suceder que en nuestro modelo de cinco estados todos los procesos en memoria estén esperando en el estado Espera y que no haya más memoria disponible para nuevos procesos. Podría conseguirse más memoria, aunque es probable que esto sólo permita procesos más grandes y no necesariamente nuevos procesos. Además hay un costo asociado a la memoria y de cualquier forma es probable que se llegaría al mismo estado con el tiempo. Otra solución es el intercambio. El intercambio se lleva a cabo moviendo una parte de un proceso o un proceso completo desde la memoria principal al disco, quedando en el estado Suspendido. Después del intercambio, se puede aceptar un nuevo proceso o traer a memoria un proceso suspendido anteriormente. El problema que se presenta ahora es que puede ser que si se decide traer a memoria un proceso que está en el estado Suspendido, el mismo todavía se encuentre en espera. Sólo convendría traerlo cuando ya está listo para ejecutar, esto implica que ya aconteció el suceso que estaba esperando. Para tener esta diferenciación entre procesos suspendidos, ya sean listos como en espera, se utilizan cuatro estados: Listo, Espera, Espera y suspendido y Listo y suspendido.
Procesos Suspendidos (Hold)
Dos o más procesos pueden cooperar mediante señales de forma que uno obliga a detenerse a los otros hasta que reciban una señal para continuar.
La sincronización explícita entre procesos es un caso particular del estado "bloqueado". En este caso, el suceso que permite desbloquear un proceso no es una operación de entrada/salida, sino una señal generada a propósito por el programador desde otro proceso
Un hilo de ejecución, en sistemas operativos, es una característica que permite a una aplicación realizar varias tareas concurrentemente. Los distintos hilos de ejecución comparten una serie de recursos tales como el espacio de memoria, los archivos abiertos, situación de autenticación, etc. Esta técnica permite simplificar el diseño de una aplicación que debe llevar a cabo distintas funciones simultáneamente.
Los hilos de ejecución que comparten los mismos recursos, sumados a estos recursos, son en conjunto conocidos como un proceso. El hecho de que los hilos de ejecución 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.
Lo que es propio de cada hilo es el contador de programa, la pila de ejecución y el estado de la CPU (incluyendo el valor de los registros).
El proceso sigue en ejecución mientras al menos uno de sus hilos de ejecución siga activo. Cuando el proceso es terminado, todos sus hilos de ejecución también lo son. Asimismo en el momento en el que todos los hilos de ejecución finalizan, el proceso no existe más y todos sus recursos son liberados.
Algunos lenguajes de programación tienen características de diseño expresamente creadas para permitir a los programadores lidiar con hilos de ejecución (como Java). Otros (la mayoría) desconocen la existencia de hilos de ejecución y éstos deben ser creados mediante llamadas de biblioteca especiales que dependen del sistema operativo en el que estos lenguajes están siendo utilizados (como es el caso del C y del C++).
Un ejemplo de la utilización de hilos es tener un hilo atento a la interfaz gráfica (iconos, botones, ventanas), mientras otro hilo hace una larga operación internamente. De esta manera el programa responde de manera más ágil a la interacción con el usuario. También pueden ser utilizados por una aplicación servidora para dar servicio a múltiples clientes.
Sincronización de hilos
Todos los hilos comparten el mismo espacio de direcciones y otros recursos como pueden ser archivos abiertos. Cualquier modificación 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 programación multihilo es que los programas operan con mayor velocidad en sistemas de computadores con múltiples CPUs (sistemas multiprocesador o a través de grupo de máquinas) ya que los hilos del programa se prestan verdaderamente para la ejecución 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 también están 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 atómicas para impedir que los datos comunes sean cambiados o leídos mientras estén siendo modificados, para lo que usualmente se utilizan los semáforos. El descuido de esto puede generar interbloqueo.
Formas de multihilos
Los sistemas operativos generalmente implementan hilos de dos maneras:
Multihiloapropiativo: permite al sistema operativo determinar cuándo 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 fenómeno conocido como inversión de prioridades y otros problemas.
Multihilo cooperativo: depende del mismo hilo abandonar el control cuando llega a un punto de detención, 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 característica fue introducida por Intel en el Pentium 4, bajo el nombre de HyperThreading?.
Usos más comunes
Trabajo interactivo y en segundo plano
Por ejemplo, en un programa de hoja de cálculo un hilo puede estar visualizando los menús y leer la entrada del usuario mientras que otro hilo ejecuta las órdenes y actualiza la hoja de calculo. Esta medida suele aumentar la velocidad que se percibe en la aplicación, permitiendo que el programa pida la orden siguiente antes de terminar la anterior.
Procesamiento asíncrono
Los elementos asíncronos 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 función guardar una copia de respaldo mientras se continúa con la operación de escritura por el usuario sin interferir en la misma.
Aceleración de la ejecución
Se pueden ejecutar, por ejemplo, un lote mientras otro hilo lee el lote siguiente de un dispositivo.
Implementaciones
Hay dos grandes categorías en la implementación de hilos:
Hilos a nivel de usuario
Hilos a nivel de Kernel
También conocidos como ULT (UserLevelThread) y KLT (KernelLevelThread)
Hilos a nivel de usuario (ULT) En una aplicación ULT pura, todo el trabajo de gestión de hilos lo realiza la aplicación y el núcleo o kernel no es consciente de la existencia de hilos. Es posible programar una aplicación como multihilo mediante una biblioteca de hilos. La misma contiene el código para crear y destruir hilos, intercambiar mensajes y datos entre hilos, para planificar la ejecución 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 asignándole 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 están 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.
Se puede realizar una planificación específica. Dependiendo de que aplicación sea, se puede decidir por una u otra planificación según sus ventajas.
Los ULT pueden ejecutar en cualquier sistema operativo. La biblioteca de hilos es un conjunto compartido. Desventajas de los ULT
En la mayoría de los sistemas operativos las llamadas al sistema (Systemcalls) son bloqueantes. Cuando un hilo realiza una llamada al sistema, se bloquea el mismo y también el resto de los hilos del proceso.
En una estrategia ULT pura, una aplicación multihilo no puede aprovechar las ventajas de los multiprocesadores. El núcleo asigna un solo proceso a un solo procesador, ya que como el núcleo no interviene, ve al conjunto de hilos como un solo proceso.
Hilos a nivel de núcleo (KLT)
En una aplicación KLT pura, todo el trabajo de gestión de hilos lo realiza el kernel. En el área de la aplicación no hay código de gestión de hilos, únicamente un API (interfaz de programas de aplicación) para la gestión de hilos en el núcleo. Windows 2000, Linux y OS/2 utilizan este método. Linux utiliza un método muy particular en que no hace diferencia entre procesos e hilos, para linux si varios proceso creados con la llamada al sistema “clone” comparten el mismo espacio de direcciones virtuales el sistema operativo los trata como hilos y lógicamente son manejados por el kernel. Ventajas de los KLT
El kernel puede planificar simultáneamente múltiples hilos del mismo proceso en múltiples 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 combinación de ULT y KLT, como Solaris.
La creación de hilos, así como la mayor parte de la planificación y sincronización de los hilos de una aplicación se realiza por completo en el espacio de usuario. Los múltiples ULT de una sola aplicación se asocian con varios KLT. El programador puede ajustar el número de KLT para cada aplicación y máquina para obtener el mejor resultado global.
Hilos Y Multihilos
Threads llamados procesos ligeros o contextos de ejecución.
• Típicamente, cada thread controla un único aspecto dentro de un programa.
• Todos los threads comparten los mismos recursos, al contrario que los procesos en donde cada uno tiene su propia copia de código y datos (separados unos de otros).
Modelos híbridos
AMOEBA, de la Universidad Libre de Amsterdam. Consiste en: sistema de estaciones y servidores más un pool de procesadores. Funcionalidad mixta: estaciones para las aplicaciones interactivas. procesadores variados. servidores especializados. Características:
Kernel pequeño: planificación y paso de mensajes.
el SO corre como procesos de usuario.
servicio de gateway a WAN.
gestión del pool mediante un servidor de carga y otro de procesos.
Ventajas:
recursos de procesamiento ajustados a las necesidades del usuario.
ejecución concurrente.
acceso a través de terminales (precio).
Requisitos y características de un SOD.
Características
Compartición de recursos (resource sharing)
Definición de recurso: rango de "cosas" que pueden ser compartidas en un sistema distribuido, de forma útil. Desde componentes HW (disqueteras, impresoras) a entidades SW (ficheros, ventanas, bases de datos).
Dispositivos HW: se comparten para reducir costes.
SW: compartición de herramientas de desarrollo, ficheros, facilidad de actualización.
Groupware.
Gestor de recursos: módulo SW que gestiona un conjunto de recursos de un tipo particular. Para cada conjunto de recursos existe un número de políticas diferentes, pero tambien características comunes.
Modelos de gestión de recursos:
Modelo Cliente/Servidor
UNIX.
Necesidad de centralización de gestión.
Necesidad de diferenciar entre servidor y servicio.
Inconveniente: algunas aplicaciones pueden requerir una cooperación más directa entre clientes.
Modelo orientado a objetos
Cada recurso es visto como un objeto, unívocamente identificado, y móvil.
Ventajas: simplicidad, flexibilidad. Los objetos pueden actuar como usuarios de recursos y como gestores de recursos.
Se necesita un gestor de objetos: colección de procedimientos y datos que caracterizan una clase de objetos.
Ejemplos: Argus, Amoeba, Mach.
3.3.1 El Modelo de Estación de Trabajo.
El sistema consta de estaciones de trabajo (PC) dispersas conectadas entre sí mediante una red de área local (LAN).
Pueden contar o no con disco rígido en cada una de ellas.
Los usuarios tienen:
Uso de los discos en las estaciones de trabajo:
—Sin disco:
—Disco para paginación y archivos de tipo borrador:
—Disco para paginación, archivos de tipo borrador y archivos binarios (ejecutables):
—Disco para paginación, borrador, binarios y ocultamiento de archivos:
—Sistema local de archivos completo:
3.3.2 El Modelo de la Pila de Procesadores
Se dispone de un conjunto de cpu que se pueden asignar dinámicamente a los usuarios según la demanda.
Los usuarios no disponen de estaciones de trabajo sino de terminales gráficas de alto rendimiento.
No existe el concepto de propiedad de los procesadores, los que pertenecen a todos y se utilizan compartidamente.
El principal argumento para la centralización del poder de cómputo como una pila de procesadores proviene de la teoría de colas:
-Se pueden permitir pequeños lapsos de tiempo en los que la tasa de entrada exceda a la de servicio.
-T = 1 / ( m - l ).
-Cuando “ l ” tiende a “0”, “T” no tiende a “0”.
-Si reunimos todas las cpu y formamos una sola pila de procesadores tendremos un solo sistema de colas en vez de “n” colas ejecutándose en paralelo.
-La tasa de entrada será “n l”, la tasa de servicio será “n m” y el tiempo promedio de respuesta será:
¡T1 = 1 / (n m - n l) = 1 / n ( m - l) = T / n.
-Conclusión: si reemplazamos “n” pequeños recursos por uno grande que sea “n” veces más poderoso:
Podemos reducir el tiempo promedio de respuesta “n” veces.
El modelo de pila es más eficiente que el modelo de búsqueda de estaciones inactivas.
También existe el modelo híbrido que consta de estaciones de trabajo y una pila de procesadores.
Hibrido
• Modelo Híbrido:
– Los trabajos interactivos se ejecutan en las estaciones de trabajo mientras que los no interactivos se ejecutan en la pila de procesadores.
• El Modelo de las Estaciones de trabajo suele coincidir en la actualidad con la mayoría de las organizaciones.
– Cuando se utiliza este modelo hay una serie de aspectos a tener en cuenta:
• La asignación de Procesos a los Procesadores.
• Los Algoritmos de Distribución de la Carga.
– • La Planificación de los Procesos en un Sistema Distribuido.
AMOEBA, de la Universidad Libre de Amsterdam. Consiste en: sistema de estaciones y servidores más un pool de procesadores. Funcionalidad mixta: estaciones para las aplicaciones interactivas. procesadores variados. servidores especializados. Características:
Kernel pequeño: planificación y paso de mensajes.
el SO corre como procesos de usuario.
servicio de gateway a WAN.
gestión del pool mediante un servidor de carga y otro de procesos.
Ventajas:
recursos de procesamiento ajustados a las necesidades del usuario.
ejecución concurrente.
acceso a través de terminales (precio).
Requisitos y características de un SOD.
Características
Compartición de recursos (resource sharing)
Definición de recurso: rango de "cosas" que pueden ser compartidas en un sistema distribuido, de forma útil. Desde componentes HW (disqueteras, impresoras) a entidades SW (ficheros, ventanas, bases de datos).
Dispositivos HW: se comparten para reducir costes.
SW: compartición de herramientas de desarrollo, ficheros, facilidad de actualización.
Groupware.
Gestor de recursos: módulo SW que gestiona un conjunto de recursos de un tipo particular. Para cada conjunto de recursos existe un número de políticas diferentes, pero tambien características comunes.
3.4 Asignación de Procesadores
Son necesarios algoritmos para decidir cuál proceso hay que ejecutar y en qué máquina [25, Tanenbaum].
Para el modelo de estaciones de trabajo:
Para el modelo de la pila de procesadores:
.
3.4.1 Modelos Algoritmos Diseño Implantación
Aspectos del Diseño de Algoritmos de Asignación de Procesadores
Los principales aspectos son los siguientes:
Algoritmos deterministas vs. heurísticos.
Algoritmos centralizados vs. distribuidos.
Algoritmos óptimos vs. subóptimos.
Algoritmos locales vs. globales.
Algoritmos iniciados por el emisor vs. iniciados por el receptor.
Los algoritmos deterministas son adecuados cuando se sabe anticipadamente todo acerca del comportamiento de los procesos, pero esto generalmente no se da, aunque puede haber en ciertos casos aproximaciones estadísticas. Los algoritmos heurísticos son adecuados cuando la carga es impredecible.
Los diseños
centralizados permiten reunir toda la información en un lugar y tomar una mejor decisión; la desventaja es que la máquina central se puede sobrecargar y se pierde robustez ante su posible falla.
Generalmente los algoritmos óptimos consumen más recursos que los subóptimos, además, en la mayoría de los sistemas reales se buscan soluciones subóptimas, heurísticas y distribuidas.
Cuando se va a crear un proceso se debe decidir si se ejecutará en la máquina que lo genera o en otra (política de transferencia):
La decisión se puede tomar “solo con información local” o “con información global”.
Los algoritmos locales son sencillos pero no óptimos.
Los algoritmos globales son mejores pero consumen muchos recursos.
Cuando una máquina se deshace de un proceso la política de localización debe decidir dónde enviarlo:
Necesita información de la carga en todas partes, obteniéndola de:
Un emisor sobrecargado que busca una máquina inactiva.
Un receptor desocupado que busca trabajo.
‘’‘ Aspectos de la Implantación de Algoritmos de Asignación de Procesadores’‘’
Casi todos los algoritmos suponen que las máquinas conocen su propia carga y que pueden informar su estado:
La medición de la carga no es tan sencilla.
Un método consiste en contar el número de procesos (hay que considerar los procesos latentes no activos). Otro método consiste en contar solo los procesos en ejecución o listos.
También se puede medir la fracción de tiempo que la cpu está ocupada.
Otro aspecto importante es el costo excesivo en consumo de recursos para recolectar medidas y desplazar procesos, ya que se debería considerar el tiempo de cpu, el uso de memoria y el ancho de banda de la red utilizada por el algoritmo para asignación de procesadores.
Se debe considerar la complejidad del software en cuestión y sus implicancias para el desempeño, la correctez y la robustez del sistema.
Si el uso de un algoritmo sencillo proporciona casi la misma ganancia que uno más caro y más complejo, generalmente será mejor utilizar el más sencillo.
Se debe otorgar gran importancia a la estabilidad del sistema:
Las máquinas ejecutan sus algoritmos en forma asíncrona por lo que el sistema nunca se equilibra.
La mayoría de los algoritmos que intercambian información:
Son correctos luego de intercambiar la información y de que todo se ha registrado.
Son poco confiables mientras las tablas continúan su actualización, es decir que se presentan situaciones de no equilibrio
—TOMA EN CUENTA LOS PATRONES DE COMUNICACION ENTRE LOS PROCESOS DURANTE LA PLANIFICACION.
—DEBE GARANTIZAR QUE TODOS LOS MIEMBROS DEL GRUPO SE EJECUTEN AL MISMO TIEMPO.
—SE EMPLEA UNA MATRIZ CONCEPTUAL DONDE:
—CADA PROCESADOR DEBE UTILIZAR UN ALGORITMO DE PLANIFICACION ROUND ROBIN:
—SE DEBEN MANTENER SINCRONIZADOS LOS INTERVALOS DE TIEMPO.
—TODOS LOS MIEMBROS DE UN GRUPO SE DEBEN COLOCAR EN EL MISMO N° DE ESPACIO DE TIEMPO PERO EN PROCESADORES DISTINTOS.
3.6 Siatemas Distribuidos de Tiempo Real