Unidad 3 Procesos y Procesadores en sistemas distribuidos 3.1 Procesos y Procesadores conceptos básicos Proceso
Formalmente un proceso es "Una unidad de actividad que se caracteriza por la ejecución de una secuencia de instrucciones, un estado actual, y un conjunto de recursos del sistemas asociados". Los procesos son gestionados por el sistema operativo y están formados por: Las instrucciones de un programa destinadas a ser ejecutadas por el microprocesador. Su estado de ejecución en un momento dado, esto es, los valores de los registros de la unidad central de procesamiento para dicho programa. Su memoria de trabajo, es decir, la memoria que ha reservado y sus contenidos. 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 eliminados 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. Si un proceso está esperando una señal, se suspende hasta que la señal se envíe. Se mantiene una cola de procesos en espera en el semáforo. La forma de elegir los procesos de la cola en espera es mediante una política first in first out. 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. Hay cuatro eventos principales que provocan la creación de procesos: El arranque del sistema. La ejecución, desde un proceso, de una llamada al sistema para la creación de otro proceso. Una petición de usuario para crear un proceso. El inicio de un trabajo por lote
El Procesador
Este es el cerebro del computador. Dependiendo del tipo de procesador y su velocidad se obtendrá un mejor o peor rendimiento. Hoy en día existen varias marcas y tipos. Las familias (tipos) de procesadores compatibles con el PC de IBM usan procesadores x86. Esto quiere decir que hay procesadores 286, 386, 486, 586 y 686. Ahora, Intel se le ocurrió que su procesador 586 no se llamaría así sino "Pentium". "Pentium".
Existen, hoy en día tres marcas de procesadores: AMD, Cyrix e Intel. Intel tiene varios como son Pentium, Pentium MMX, Pentium Pro y Pentium II. AMD tiene el AMD586, K5 y el K6. Cyrix tiene el 586, el 686, el 686MX y el 686MXi. Los 586 ya están totalmente obsoletos y no se deben considerar siquiera. La velocidad de los procesadores se mide en Megahertz (MHz =Millones de ciclos por segundo). Así que un Pentium es de 166Mhz o de 200Mhz, etc. Este parámetro indica el número de ciclos de instrucciones que el procesador realiza por segundo, pero sólo sirve para compararlo con procesadores del mismo tipo. 3.2 Hilos y Multihilos
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. 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: 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 TREADING .
3.3 Modelos de procesadores 3.3.1 De estación de trabajos
Este modelo es directo: el sistema consta de estaciones de trabajo dispersas en un edificio o campus y conectadas entre sí por medio de una LAN de alta velocidad. Algunas de las estaciones pueden estar en oficinas, con lo que de manera implícita, cada una de ellas se dedica a un usuario, mientras que otras pueden estar en aéreas publicas y tener distintos usuarios en el transcurso del día. En ambos casos, en un instante dado, una estación de trabajo puede tener un usuario conectador a ella y tener entonces un poseedor o estar inactiva. En ciertos sistemas, pueden tener discos locales o en otros no. Los últimos reciben el nombre universal de estaciones de trabajo sin disco, pero las otras tienen nombres variados, como estaciones de trabajo con disco. Si las estaciones carecen de disco, el sistema de archivos debe ser implantado mediante uno o varios servidores en la red. Las solicitudes de lectura o escritura se envían a un servidor de archivos, el cual realiza el trabajo y envía de regreso las respuestas. Si la estación de trabajo tiene sus propios discos, estos se pueden utilizar al menos de cuatro maneras:
Paginación y archivos temporales. Paginación, archivos temporales y binarios del sistema. Paginación, archivos temporales, binarios del sistema y sistema de ocultamiento de archivos. Un sistema local de archivos completo.
3.3.2 De pila de procesadores
Otro método más es el de una pila de procesadores, repleta de CPU, en el cuarto de las maquinas, los cuales se pueden asignar de manera dinámica a los usuarios según la demanda. Este método en vez de darle a los usuarios estaciones de trabajo personales, se les dan terminales graficas de alto rendimiento, como las terminales X. Esta se basa en la observación de que lo que en realidad quieren muchos usuarios es una interfaz grafica de alta calidad y un buen desempeño. Este método se parece mucho al de tiempo compartido tradicional que al modelo de la computadora personal aunque que se construye con la tecnología moderna. La idea de este modelo es dar un paso más adelante en la idea de las estaciones de trabajo sin disco. Si el sistema de archivos se debe concentrar en un pequeño número de servidores de archivos para mayor economía, debe ser posible hacer lo mismo con los servidores de cómputo. De hecho, convertimos todo el poder de cómputo en estaciones de trabajo inactivas a las que se puede tener acce so de manera dinámica. Los usuarios obtienen tantos CPU’s como sea necesario, durante periodos cortos, después de lo cual regresan a la pila, de modo que otros usuarios puedan disponer de ellos. En este caso no existe el concepto de propiedad: todos los procesadores pertenecen por igual a todos.
3.3.3 Hibrido
Se puede establecer una mediación al proporcionar a cada usuario una estación de trabajo personal y además tener una pila de procesadores. Aunque esta solución es más cara que cualquiera de los dos modelos puros, combina las ventajas de ambos. El trabajo interactivo se puede llevar a cabo en las estaciones de trabajo, con una respuesta garantizada. Sin embargo, las estaciones inactivas no se utilizan, lo cual hace más sencillo el diseño del sistema. Solo se dejan sin utilizar. En vez de esto, todos los procesos no interactivos se ejecutan en la pila de procesadores, así como todo el cómputo pesado en general, este modelo proporciona una respuesta interactiva más rápida, un uso eficiente de los recursos y un diseño sencillo. 3.4 Asignación de Procesadores
Un sistema distribuido consta de varios procesadores. Estos se pueden organizar como colección estaciones de trabajo personales, una pila publica de procesadores o alguna forma hibrida. Se necesita cierto algoritmo para decidir cual proceso hay que ejecutar y en que maquina. 3.4.1 Modelos y Algoritmos con sus aspectos de diseño e implementación
Las estrategias de asignación de procesadores se pueden dividir en 2 categorías amplias: No migratoria: al crearse un proceso, se toma una decisión acerca de dónde colocarlo. Una vez colocado en una maquina, el proceso permanece ahí hasta que termina. No se puede mover, no importa la sobrecarga que este la maquina ni que existan muchas otras maquinas inactivas. Migratorias: un proceso se puede trasladar aunque haya iniciado su ejecución. Mientras que las estrategias migratorias permiten un mejor balance de la carga, son más complejas y tiene un efecto fundamental en el diseño del sistema.
Algoritmos deterministas son adecuados cuando se sabe de antemano todo acerca del comportamiento de los procesos; si no es que en ninguno de los sistemas, se tiene un conocimiento total de antemano, pero a veces se puede obtener una aproximación razonable. Algoritmos Heurísticos están los sistemas donde la carga es por completo impredecible. Las solicitudes de trabajo, dependen de quien está haciendo que, y puede variar de manera drástica cada hora, e incluso cada minuto. La asignación de procesadores en tales sistemas no se puede hacer de manera determinista o matemática, sino que por necesidad y utiliza técnicas ad hoc. Algoritmos centralizados vs distribuido es la recolección de toda la información en un lugar permite tomar una mejor decisión, pero menos robusta y coloca una carga pesada en la maquina central. Son preferibles los algoritmos descentralizados, pero hay algunos centralizados por la carencia de alternativas descentralizadas adecuadas. Algoritmos óptimos vs subo timos ya que se puede obtener soluciones optimas tanto en los sistemas centralizados como en los descentralizados, pero por regla son más caros que los subo timos. Hay que recolectar más información y procesarla un poco más. En la práctica, la mayoría de los sistemas distribuidos reales buscan soluciones su optimas, heurísticas y distribuidas, debido a la dificultad para obtener optimas. Algoritmos locales vs globales, a veces llamado política de transferencia es cuando se está a punto de crear un proceso, hay que tomar una decisión para ver si se ejecuta o
no en la maquina que lo genera. Si esa máquina está muy ocupada, hay que transferir a otro lugar el nuevo proceso. La opción en este aspecto consiste en basar o no la decisión de transferencia por completo en la información local. Los algoritmos locales son sencillos, pero están muy lejos de ser los óptimos, mientras que los globales solo dan un resultado poco mejor a un costo mayor. Algoritmos iniciados por el emisor vs iniciados por el receptor que trata de la política de localización, ya que una vez que la política de transferencia ha decidido deshacerse de un proceso, esta debe decidir donde enviarlo. Es claro que no es local. Necesita información de la carga en todas partes para tomar una decisión inteligente. Sin embargo, esta información se puede dispersar de dos maneras, en uno los emisores inician el intercambio de información, y el otro el receptor toma la iniciativa.
Implantación.
Un aspecto es el enfrentamiento con el costo excesivo. Muchos de los algoritmos teóricos para la asignación de procesos ignoran el costo de recolectar medidas y desplazar los procesos de aquí para allá. Otro aspecto a consideración es la complejidad ya que se mide la calidad de sus algoritmos mediante el análisis de datos analíticos, simulados o experimentales del uso del CPU y de la red, así como el tiempo de respuesta. 3.5 Co-planificación
No hay mucho que decir de la planificación en los sistemas distribuidos, por lo general, cada procesador hace su planificación local (si tiene varios procesos en ejecución), sin preocuparse por lo que hacen los demás procesadores. Lo normal es que este método funcione. Sin embargo, si un grupo de procesos relacionados entre si y con gran interacción se ejecutan en distintos procesadores, la planificación impediente no es el camino más eficiente. Lo que se necesita es una forma de garantizar que los procesos con comunicación frecuente se ejecuten de manera simultánea. Aunque es difícil en forma dinámica los patrones de comunicación entre los procesos, en muchos casos, un grupo de procesos relacionados entre si iniciaran juntos. Ousterhout propuso la co-planificación, el cual toma en cuenta los patrones de comunicación entre los procesos durante la planificación para garantizar que los todos los miembros de un grupo se ejecutan al mismo tiempo. La esencia de esta idea es que cada procesador utilice un algoritmo de planificación round robin, donde todos los procesadores ejecuten el proceso en el espacio 0 durante un cierto periodo fijo, para que después todos los procesadores ejecuten el proceso del espacio 1 durante un cierto periodo fijo. Se puede utilizar un mensaje para indicarle a cada procesador el momento en que debe hacer un intercambio de procesos, para mantener sincronizados los intervalos de tiempo. 3.6 Tolerancia a fallos
Decimos que un falla cuando no cumple su especificación. Como en un sistema distribuido para el control aéreo, una falla no es buena señal. Como las computadoras y los sistemas distribuidos se utilizan cada vez más en misiones donde la seguridad es crítica, la necesidad de evitar las fallas es cada vez mayor.
Fallas de componentes
Los sistemas de cómputo pueden fallar debido a una falla en algún componente, como procesador, la memoria, un dispositivo de E/S, un cable o el software. Una falla es un desperfecto, causando tal vez por un error de diseño, un error de fabricación, un error de programación, un daño físico, el deterioro con el curso de tiempo, condiciones ambientales adversas, entradas inesperadas, un error del operador, roedores comiendo parte del sistema y muchas otras causas. Estas fallas se pueden clasificar en:
Fallas transitorias. Estas ocurren una vez y después desaparecen. Si la operación se repite, la falla ya no se presenta. Fallas intermitente. Esta desaparece, reaparece, etc. Un mal contacto de un conector causa con frecuencia una falla intermitente, las cuales son graves por su difícil diagnostico. Falla permanente. Es aquella que continua existiendo hasta reparar el componente con el desperfecto. Los circuitos quemados. Los errores del software y el rompimiento de la cabeza del disco provocan con frecuencia fallas permanentes.
El objetivo del diseño y construcción de sistemas tolerantes a fallas consiste en garantizar que el sistema continúe funcionando de manera correcta como un todo, incluso en la presencia de fallas. El trabajo tradicional en el área de tolerancia de fallas se ha preocupado principalmente del análisis estadístico de las fallas de los componentes electrónicos. Fallas de sistema
En un sistema distribuido crítico, con frecuencia nos interesa que el sistema pueda sobrevivir a las fallas de los componentes, en vez de hacer que las fallas sean pocos probables. La confiabilidad de un sistema es en particular importante en un sistema distribuido, debido a la gran cantidad de componentes presentes, de ahí la mayor posibilidad de que falle uno de ellos. Se pueden distinguir dos tipos de fallas del procesador:
Fallas silentes. Un procesador que falla solo se detiene y no responde a las entradas subsecuentes ni produce más entradas, excepto que puede anunciar que ya no está funcionando. Fallas bizantinas. Un procesador que falla continúa su ejecución, proporcionando respuestas correctas a las preguntas, y posiblemente trabajando de manera maliciosa junto con otros procesadores que han fallado, para dar la impresión de que todos funcionan de manera correcta aunque no sea así. Los errores no detectados en el software exhiben con frecuencia fallas bizantinas.
Sistemas síncronos vs asíncronos
Un sistema que tiene la propiedad de responder siempre a un mensaje dentro de un límite finito conocido, si está funcionando, es síncrono. Un sistema que no tiene esta propiedad es asíncrono. Debe ser claro que los sistemas asíncronos serán mas difíciles de tratar que los síncronos. Si un procesador puede enviar un mensaje y sabe que la usencia de respuesta dentro t segundos significa que el pretendido receptor ha fallado, puede realiza una acción correctiva. Si no existe una cota superior para el tiempo de la respuesta, será un problema determinar incluso si ha ocurrido una falla.
Uso de redundancia
El método general para la tolerancia de fallas consiste en el uso de redundancia. Existen 3 tipos posibles:
Redundancia de la información. Donde se agregan algunos bits para poder recuperar los bits devueltos. Redundancia del tiempo. Donde se realiza una acción, y entonces, en caso necesario, se vuelve a realizar. El uso de las transacciones atómicas descrito es un ejemplo de este. Si una transacción aborta, puede volverse a realizar sin daño alguno. la redundancia de tiempo es de particular utilidad cuando las fallas son transitorias o intermitente. Redundancia física. Donde se agrega un equipo adicional para permitir que el sistema como un todo tolere la pérdida o el mal funcionamiento de algunos componentes.
Tolerancia de fallas mediante replica activa
Es una técnica muy conocida para proporcionar la tolerancia de fallas mediante la redundancia física. Se utiliza en la biología, aviación y los deportes. Aunque no todos los sistemas operativos distribuidos tolerantes de fallas utilizan TMR (Triple Modular Redundancy, donde si dos entradas son iguales, la salida es igual a esa entrada, pero si las tres entradas son diferentes, la salida queda indefinida), la técnica es muy general y debe proporcionar una clara idea de lo que es un sistema tolerante, en oposición a un sistema cuyos componentes individuales son muy confiables, pero cuya organización no tolera las fallas. Tolerancia de fallas mediante respaldo primario
La idea esencial es que en cualquier instante, un servidor es el primario y realiza todo el trabajo. Si el primario falla, el respaldo ocupa su lugar. El reemplazo debe ocurrir de manera limpia, y ser notado únicamente por el sistema operativo cliente, no por los programas de aplicación. Este tiene 2 ventajas sobre la réplica activa. En primer lugar, es más sencilla durante la operación normal, puesto que los mensajes van solo a un servidor (primario) y no a todo un grupo. En segundo lugar, en la práctica se requieren menos maquinas, puesto que en cualquier instante se necesitan un primario y un respaldo. Como desventaja, trabaja mal en presencia de fallas bizantinas, en las que el primario afirma erróneamente que funciona de manera perfecta. Además, la recuperación de una falla del primario puede ser compleja y consumir mucho tiempo. 3.7 Sistemas distribuidos de tiempo real
Los sistemas tolerantes de fallas no son el único tipo de sistemas distribuidos especializados. Los sistemas de tiempo real forman otra categoría. A veces se combinan estos dos tipos para obtener sistemas de tiempo real tolerantes de fallas. Para la mayoría de los programas, el hecho de que sean correctos depende solo de la secuencia lógica de las instrucciones ejecutadas, no del momento en que se ejecuten. Los programas de tiempo real interactúan con el mundo exterior de una manera que implica al tiempo. Cuando aparece un estimulo, el sistema responde a este de cierta manera y antes de cierto momento limite. Si entre la respuesta correcta, pero después del límite, se considera
que el sistema está fallando. El momento en que se produce las respuestas es tan importante como aquello que produce. Muchas aplicaciones y sistemas de tiempo real son muy estructurados, mucho mas que los sistemas distribuido de propósito general. De manera típica, un dispositivo externo genera un estimulo para la computadora, la que entonces debe realizar ciertas acciones antes de un momento limite. Al terminar el trabajo solicitado, el sistemas queda inactivo hasta que llegar el siguiente estimulo. En consecuencia, algunos diseñadores están experimentando con la idea de colocar un microprocesador exclusivo al frente de cada dispositivo de tiempo real para aceptar salida de ella cuando tenga algo que decir, y dar una entrada con la velocidad que requiera. Los sistemas distribuidos de tiempo real con frecuencia se estructuran, como una colección de computadoras conectadas mediante una red. Algunas de estas se conectan a dispositivos externos que producen o aceptan datos o esperar ser controlados en tiempo real. Las computadoras pueden ser pequeños micro controladores integrados a los dispositivos, o maquinas independientes. En ambos casos, por lo general tiene sensores para recibir señales de los dispositivos y/o actores a los cuales enviar señales. Los sensores pueden ser digitales o analógicos. Los sistemas de tiempo real se clasifican por lo general en 2 tipos dependiendo de los serio de sus tiempos limite y de las consecuencias de omitir uno de ellos. Estos son:
Sistemas de tiempo real suave. Significa que no existe problema si se rebasa un tiempo límite. Sistemas de tiempo real duro. Un tiempo límite no cumplido es inaceptable, pues podría conducir a la perdida de una vida o a una catástrofe ambiental.
En la práctica, existen también sistemas intermedios en los que la omisión de un tiempo límite significa que falla toda la actividad actual, pero que la consecuencia no es fatal. Además en algunos sistemas de tiempo real, algunos subsistemas son de tiempo real duro, mientras que otros son de tiempo real suave. Stankovic señala: Mito 1: Los sistemas de tiempo real tratan de la escritura de controladores de dispositivos en condigo ensamblador.
Hace década los sistemas de tiempo real que constaba de unos cuantos instrumentos conectados a una minicomputadora, pero los sistemas de tiempo real de la actualidad son muy complicados para confiar en el lenguaje ensamblador y escribir los controladores de dispositivos es la menor de las preocupaciones de un diseñador de sistemas de tiempo real. Mito 2: El cómputo de tiempo real es rápido.
No necesariamente. Un telescopio controlado por una computadora puede tener que rastrear las estrellas, aquí lo que cuenta es la exactitud.
Mito 3: Las computadoras rápidas harán que el sistema de tiempo real sea obsoleto.
No solo animan a las personas a construir sistemas de tiempo real que anteriormente estaban más allá de lo normal. Además, para crear sistemas más rápidos mediante el uso de varios procesadores hay que resolver nuevos problemas de comunicación, sincronización y planificación. Aspectos del diseño
Los sistemas distribuidos de tiempo real tienen c iertos aspectos de diseños único, tales como:
Sincronización del reloj. Es el mantenimiento de la propia hora. Con varias computadoras, cada una con su propio reloj local, la sincronización de los relojes es un aspecto fundamental. Predictibilidad. Una de las propiedades más importantes de cualquier sistema de tiempo real es que si comportamiento sea predecible. De manera ideal, debe ser claro en el momento del diseño que el sistema cumple con todos sus tiempos límite, incluso con carga pico. Tolerancia de fallas. Muchos sistemas de tiempo real controlan dispositivos donde la seguridad es crítica, es de particular importancia que el sistema pueda controlar el peor de los escenarios. Además estos sistemas deben poder enfrentar el número máximo de fallas y la carga máxima al mismo tiempo
