domingo, 10 de abril de 2011

3.7 SISTEMAS DISTRIBUIDOS EN TIEMPO REAL.


Los sistemas de tiempo real son aquellos que interactúan con el mundo exterior donde el tiempo es un factor importante.
 Característica:
Se activan por evento o por tiempo.
Su comportamiento debe ser  predecible.
Deben ser tolerantes a fallas.
La comunicación en los sistemas distribuidos de tiempo real debe  ser de alto desempeño.

Clasificación: 
Los sistemas de tiempo real se clasifican en general en dos tipos dependiendo de lo serio de sus tiempos límite y de las consecuencias de omitir uno de ellos. Estos son:
Sistema de tiempo real suave.
Sistema de tiempo real duro.

 El tiempo real suave significa que no existe problema si se rebasa un tiempo límite. Un sistema de tiempo real duro es aquel en el que un tiempo límite no cumplido puede resultar catastrófico.

Ejemplo de sistema de tiempo real suave.

Conmutador telefónico.

Ejemplo de sistema de tiempo real duro.

Alarma sísmica.



Activación de sistemas entiempo real: 

Los sistemas de tiempo real pueden ser activados por evento o por tiempo. Se dice que un sistema es activado por evento cuando, al ocurrir un evento externo, este es detectado por algún sensor, lo que entonces provoca que el CPU conectado tenga una interrupción. Los sistemas activados por eventos están controlados entonces por las interrupciones. Por otro lado, en los sistemas de tiempo real activados por el tiempo, se verifican los sensores cada cierto tiempo, para verificar si está ocurriendo algún evento externo. La desventaja es que se pierde mucho tiempo de CPU si los eventos ocurren con poca frecuencia.

3.6 TOLERANCIA A FALLOS

Fault Tolerance - tolerancia de fallos). Es la propiedad que permite a un sistema continuar operando adecuadamente en caso de una falla en alguno de sus componentes. La tolerancia de fallas es muy importante en aquellos sistemas que deben funcionar todo el tiempo.

Ante una falla, otro componente o un procedimiento especial de respaldo pueden tomar el control para subsanar o amortiguar los efectos del fallo. Una forma de lograr tolerancia de fallas, es duplicar cada componente del sistema.
Sistemas distribuidos en tiempo real:
(Además de ser correctos) se produzcan a tiempo
A muy alto nivel, en la distribución en tiempo real normalmente se
Debe prescindir:
• de aspectos dinámicos como la migración y relocalización de código de esconder determinadas cosas como la localización de los servicios, o la persistencia
Es necesario evaluar temporalmente todo el software (incluido el de la red) y extraer los modelos para que puedan ser analizados:
• Implementación del middleware con pautas más estrictas
Los aspectos importantes para tiempo real siguen siendo:
• modelo de concurrencia (software y hardware) y las políticas de planificación
• la sincronización que ahora se hace más compleja si se accede a recursos compartidos remotos
Aparecen nuevos aspectos:
• sincronización de relojes cuando sea necesario uso de redes de comunicaciones predecibles
• Conceptos relativos a la calidad de servicio que cada vez se mezclan más con los de tiempo real

3.5 COPLANIFICACIÓN

La coplanificación se basa en el concepto de planificación de un conjunto de tareas afines, llamado cuerpo de tareas. Los elementos individuales de un cuerpo de tareas tienden a ser pequeños y son, por lo tanto, parecidos a la idea de hilo.
El término planificación por grupos se ha aplicado a la planificación simultánea de hilos que forman parte de un único proceso. Es necesaria para aplicaciones paralelas de grano medio a fino cuyo rendimiento se degrada seriamente cuando alguna parte de la aplicación no se está ejecutando mientras otras partes están listas para ejecutarse. Es también beneficiosa para cualquier aplicación paralela, incluso para aquellas que no son lo bastante sensibles al rendimiento. La necesidad de planificación por grupos está muy reconocida y existen implementaciones en una gran variedad de sistemas operativos de multiprocesadores.
Una razón obvia por la que la planificación por grupos mejora el rendimiento de una sola aplicación es que se minimizan los intercambios de procesos. Supóngase que un hilo de un proceso se está ejecutando y alcanza un punto en el cual debe sincronizarse con otro hilo del mismo proceso. Si ese otro hilo no se
 
está ejecutando pero está listo para ejecutarse, el primer hilo se queda colgado hasta que se puede realizar un intercambio en otro procesador para traer el hilo que se necesita. En una aplicación con una coordinación estrecha entre sus hilos, tales intercambios reducen drásticamente el rendimiento. La planificación simultánea de los hilos cooperantes puede, además, ahorrar tiempo en el reparto de recursos. Por ejemplo, varios hilos planificados por grupo pueden acceder a un archivo sin el costo adicional del bloqueo durante la operación de búsqueda, lectura y escritura.

3.4. AIGNACIÓN DE PROCESADORES

Asignación de Procesadores:
Son necesarios algoritmos para decidir cuál proceso hay que ejecutar y en qué máquina.
Para el modelo de estaciones de trabajo:
·    Decidir cuándo ejecutar el proceso de manera local y cuándo es necesario buscar estaciónes inactivas o no locales que tienen una conexion a la misma red pero fuera de ella.
Para el modelo de la pila de procesadores:
·    Decidir dónde ejecutar cada nuevo proceso respecto de la misma maquina que es la tabla(lista) de los procesos que se crean dentro de la maquina.

Modelos y algoritmos con sus respectos diseños e implementación:
·         Esta estrategia  consiste como su nombre lo indica,  en dedicar un grupo de procesadores a una aplicación mientras dure esta aplicación , de manera que cada hilo de la aplicación se le asigna un procesador.
·          
·          
·        
·          

·         Figura 10.2    Ejemplo de planificación por grupos

·                        con uno y cuatro hilos.
·          
·         Una desventaja es que si un hilo de una aplicación se bloquea en espera de una E/S  o por sincronizacion de otro hilo, el procesador de dicho hilo quedara desocupado: no hay multiprogramacion de procesadores.
·          
·         Esta forma de planificación presenta las siguientes ventajas:
·          
·         Ø              En un sistema masivamente paralelo, con decenas o cientos de procesadores cada uno de los cuales  representa una pequeña parte del coste del sistema, la utilización del procesador no es tan importante como medida de la efectividad o el rendimiento.
·          
·         Ø              La anulación total del intercambio de procesos durante el tiempo de vida de un programa dara como resultado una aceleracion sustancial del programa.
·          
·        
·          
·         Figura 10.3   Aceleración de una aplicación en función
·                             del número de procesos.
·          
·         Experiencia: se ejecutan 2 aplicaciones, una  multiplicacion de matrices y un calculo de la transformacion rapida de Fourriet ( FFT fast  fourrier transform), en un sistema con 16 trabajadores,:Cada aplicación divide el problema en una serie de tareas, que se organizan en hilos que ejecutan la aplicación. Los programas se escribieron de forma que se permitiera variar el numero de hilos empleados. Basicamente cada aplicacion define una serie de tareas y las pone en cola. Se toman tareas de la cola y se corresponden con hilos disponibles. Si  hay menos hilos que tareas , entonces las tareas restantes permanecen en la cola y son corregidas por hilos que hayan completado su tarea asignada.
·          En la figura 10.3 puede verse la representacion de la aceleracion de la aplicación a medida que el numero de hilos que esta ejecutando las tareas varia desde 1 a 24. El eje  vertical representa la aceleracion de una  aplicación   y el eje horizontal representa el numero de hilos.
·         Al inicio ambas aplicaciones tienen una aceleracion de 2,8 para un solo hilo, la figura muestra que esto empeora notablemente cuando el numero de hilos crece.
·         Una posible solucion :
·          *  Limitar el numero de hilos activos al numero de procesadores para el sistema.

·         ANALOGIA:

·         Se puede comparar analogicamente  el problema de la asignacion del procesador en un multiprocesador con el problema de la asignacion de  memoria en un monoprocesador.
·                     ¿Cómo se asignan muchos procesadores a un programa?
·          
·         Este problema podria llegar a ser equivalente a :
·                     ¿Como asignar varios marcos de pagina a un proceso en un instante dado?
·          
·         Se propone el concepto de:
·         Conjunto de trabajo de actividades 
·            
·         Analogo al:
·         Conjunto de trabajo en memoria virtual. Etc.
·          
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.
Modelos de Asignación
Generalmente se utilizan las siguientes hipótesis:
—Todas las máquinas son idénticas (o al menos compatibles en el código); difieren a lo sumo en la velocidad.
—Cada procesador se puede comunicar con los demás.
Las estrategias de asignación de procesadores se dividen en:
—No migratorias:
·    Una vez colocado un proceso en una máquina permanece ahí hasta que termina.
—Migratorias:
·    Un proceso se puede trasladar aunque haya iniciado su ejecución.
·    Permiten un mejor balance de la carga pero son más complejas.
Los algoritmos de asignación intentan optimizar algo:
—Uso de las cpu:
·    Maximizar el número de ciclos de cpu que se ejecutan para trabajos de los usuarios.
·    Minimizar el tiempo de inactividad de las cpu.
—Tiempo promedio de respuesta:
·    Minimizar no los tiempos individuales de respuesta sino los tiempos promedio de respuesta.
—Tasa de respuesta:
·    Minimizar la tasa de respuesta, que es el tiempo necesario para ejecutar un proceso en cierta máquina dividido por el tiempo que tardaría en cierto procesador de referencia.


3.3. MODELO DE PROCESADORES

3.2 MULTIHILOS Y HILOS

Hilos y Multihilos:
En sistemas operativos, un hilo de ejecución o subproceso es una característica que permite a una aplicación realizar varias tareas a la vez (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. Un hilo es básicamente una tarea que puede ser ejecutada en paralelo con otra tarea.
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 a 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 finaliza, todos sus hilos de ejecución también han terminado. 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 o Delphi). 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.


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.

Multihilo:
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:
Multihilo apropiativo: 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 Hyper Threading.
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 (User Level Thread) y KLT (Kernel Level Thread)
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 (System calls) 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.

Usos de Hilos :
Los hilos permiten la combinación del paralelismo con la ejecución secuencial y el bloqueo de las llamadas al sistema.
Consideramos el ejemplo del servidor de archivos con sus posibles organizaciones para muchos hilos de ejecución.
Iniciamos con el modelo servidor / trabajador:
  • Un hilo, el servidor, lee las solicitudes de trabajo en el buzón del sistema.
  • Elige a un hilo trabajador inactivo (bloqueado) y le envía la solicitud, despertándolo.
  • El hilo trabajador verifica si puede satisfacer la solicitud por medio del bloque caché compartido, al que tienen acceso todos los hilos.
  • Si no envía un mensaje al disco para obtener el bloque necesario y se duerme esperando el fin de la operación.
  • Se llama:
    • Al planificador y se inicializa otro hilo, que tal vez sea el servidor, para pedir más trabajo; o.
    • A otro trabajador listo para realizar un trabajo.
Los hilos ganan un desempeño considerable pero cada uno de ellos se programa en forma secuencial.
Otro modelo es el de equipo:
  • Todos los hilos son iguales y cada uno obtiene y procesa sus propias solicitudes.
  • No hay servidor.
  • Se utiliza una cola de trabajo que contiene todos los trabajos pendientes, que son trabajos que los hilos no han podido manejar.
  • Un hilo debe verificar primero la cola de trabajo antes de buscar en el buzón del sistema.
Un tercer modelo es el de entubamiento:
  • El primer hilo genera ciertos datos y los transfiere al siguiente para su procesamiento.
  • Los datos pasan de hilo en hilo y en cada etapa se lleva a cabo cierto procesamiento.
Un programa diseñado adecuadamente y que utilice hilos debe funcionar bien:
  • En una única cpu con hilos compartidos.
  • En un verdadero multiprocesador.