Documentos de Académico
Documentos de Profesional
Documentos de Cultura
26 oct
Unidad 3 Procesos y procesadores en SD.
3.1
Procesos y procesadores conceptos bsicos.
Es posible disponer en un proceso de ms de un flujo de ejecucin. A cada uno de estos flujos le
denominaremos "thread" (Hilo). La introduccin de threads en la codificacin de servidores aporta ventajas
e inconvenientes que sern estudiados en primer lugar. Por otra parte, en un SD se dispone de ms de un
procesador. A continuacin, estudiaremos las diversas formas de organizar los procesadores. Finalmente,
estudiaremos la forma de asignar un proceso entre todos los procesadores disponibles.
3.2 Hilos y multihilos
En los aos ochenta se descubri que el concepto de proceso, tal como lo entendemos en el mundo UNIX,
resultaba desproporcionado para los requisitos de los SD. El problema radica en que UNIX asocia un nico
thread de control con cada proceso. Un proceso es un recurso costoso en su creacin y en su gestin. Ello
lleva consigo que la cooperacin entre las distintas actividades de una aplicacin donde cada una de ellas ha
sido implementada como un proceso sea difcil de programar y costosa en trminos de ciclos de CPU por el
gran nmero de llamadas al sistema requeridas en la comunicacin de actividades, comunicacin de
procesos, y en la planificacin de los mismos y cambios de contexto- (Fig. 4.1).
2
la solicitud de un bloque al manejador de disco duro, otro thread toma el control sirviendo la siguiente
peticin, cuyos octetos pueden estar en la cach. La introduccin del concepto de thread aumenta la
concurrencia y las prestaciones del servidor de archivos.
La figura 4.3 a) muestra tres procesos. Cada uno de ellos tiene su propio espacio de direccionamiento y
descriptor de proceso. Los tres procesos, ya que no comparten espacio de direcciones, deben comunicarse
haciendo uso de los servicios de comunicacin de procesos ofrecidos por el sistema operativo. En la figura
4.3 b) observamos un nico proceso con tres threads de control. Cada uno de ellos tiene su propio contador
de programa y su propia pila, pero todos ellos comparten el mismo espacio de direcciones. A estos miniprocesos se les denomina threads o procesos ligeros. Por supuesto, los threads comparten el CPU en un
sistema monoprocesador. En un hardware multiprocesador, sin embargo, los threads pueden ejecutar en
paralelo. Un thread puede crear un thread hijo y, al igual que los procesos invocar, llamadas al sistema. Si un
thread se bloquea en una de estas llamadas, otra puede tomar el CPU sin que el sistema operativo necesite
cambiar de contexto.
mquina B
mquina A
procesos
contador de
programa
threads
Fig. 4.3 a) Tres procesos con un thread de control cada uno. b) Un proceso con tres threads de control.
Los threads comparten un mismo espacio de direccionamiento, de modo que no hay proteccin entre ellos,
todos tienen acceso a las variables globales del resto. El hecho es que proporcionar proteccin entre los
threads, primero, es imposible y, segundo, no es necesario. A diferencia de los procesos de usuario, los
threads son programados por un mismo programador, de modo que no deben intentar acciones perjudiciales
para el resto de los threads sino todo lo contrario y, si lo hacen debido a un error de codificacin, la
responsabilidad recae sobre el programador. Adems de compartir espacio de direccionamiento, los threads
comparten los mismos archivos abiertos, manejadores de seal, procesos hijos, etc., algo que es til cuando
los threads no son independientes, sino que colaboran en un fin comn.
3
27 oct
El contexto de un thread
La figura 4.4 muestra un programa que calcula dos valores y los suma. La figura 4.5 muestra el proceso
tradicional UNIX asociado al programa con el contexto del proceso determinado por tres bloques
distintos, los registros, la identidad del proceso y los recursos
int r_a, r_b;
main()
{
calcula_a(&r_a);
calcula_b(&r_b);
reune(r_a, r_b);
}
void calcula_a(int *res)
{
...
*res = Clculo_a();
}
void calcula_b(int *res)
{
...
*res = Clculo_b();
}
void reune(int p, int q)
{
printf("%d\n", p+q);
}
Fig. 4.4 Programa 2Fig.
4.5 El proceso de la Fig. 4.4 y su contexto
Los clculos de los valores r_a y r_b son dos actividades paralelas, de modo que cada una puede ser
soportada por un thread, segn ilustra la Fig. 4.6. Cada thread tiene su propia pila. Como se aprecia el
contexto de un thread es mucho ms ligero que el contexto de un proceso.
4
sta. Este bloqueo causar la ejecucin del planificador, que dar paso a otro thread, posiblemente el
despachador que ahora est dispuesto debido a la llegada de una nueva solicitud de acceso al disco, o
posiblemente
otro
trabajador,
que
ahora
est
dispuesto
para
tomar
el
CPU.
5
28 oct
Consideremos lo que ocurre si el servidor de archivos ha sido implementado como un proceso convencional,
es decir, con un solo thread de control. Un servidor de este tipo est escrito como un blucle infinito de espera
de peticin y servicio. Tras recibir una peticin, la sirve antes de ponerse a esperar la prxima. Si los datos
estn en la cach, la peticin se sirve de inmediato, pero si no es as, debe iniciar una transferencia de disco y
esperar a que sta concluya. En este intervalo de tiempo las nuevas peticiones que se incorporan no pueden
ser atendidas porque estn retenidas. Pudiera ser que llegasen dos peticiones con los bloques en la cach. Si
el servidor tuviese dos threads de control, mientras uno espera al disco, el otro podra servir estas dos
peticiones. La conclusin es que con el mecanismo de threads, las prestaciones del servidor aumentan
porque sirve ms peticiones por unidad de tiempo. En un servidor sin threads, una peticin que deba acceder
al disco provoca el bloqueo del sistema de archivos para que otros procesos tomen el CPU. Sin embargo, en
muchas ocasiones el servidor de disco es una mquina dedicada a esta tarea, de modo que el CPU queda
ocioso, por lo que el uso de threads queda ms justificado. Como podemos apreciar, los threads
proporcionan mayores prestaciones.
Por otra parte, los threads tambin pueden ser organizados en forma de tubera. Con este modelo, el primer
thread genera un dato que pasa a otro thread para que lo procese. Con ms de dos threads, los datos son
procesados y entregados al siguiente thread de forma sucesiva. Este modelo no es apropiado para la
construccin de servidores, pero s cuando se presenta el problema de los lectores y escritores [El problema
en cuestin es el siguiente: Hay un archivo que es utilizado por varios procesos, unos leen y otros escriben.
Slo puede utilizar el recurso un proceso y slo uno, es decir, o bien escribiendo o bien leyendo, nunca
ambos (teniendo en cuenta que si no lo est utilizando nadie, tendr preferencia el escritor ante el lector).
Se considera a cada usuario (lector y escritor) como dos procesos y al archivo como un recurso. De modo
que, para que un proceso acceda al recurso que necesita, tenemos que considerar a cada usuario como dos
semforos binarios y valen 0 si el recurso est siendo utilizado por otro proceso y 1 si dicho recurso est
disponible]. Los threads permiten resolverlo en un proceso nico. El modelo de tubera se emplea tambin
en la escritura de clientes. La figura 4.9 muestra un cliente con dos threads. El primer thread genera
resultados que deben ser almacenados en un servidor mediante una llamada RPC. Desafortunadamente, una
llamada convencional RPC es bloqueante, lo que hace esperar al cliente. Para evitarlo, el cliente puede
incorporar un segundo thread, que realiza la llamada RPC. Mientras el segundo thread permanece
bloqueado, el primero puede seguir generando nuevos resultados. Ambos threads comparten una estructura
de datos en la que actan como escritor y lector respectivamente.
Finalmente, en computadores multiprocesador, cada thread puede ser asignado a un procesador, de modo
que el proceso puede ejecutar en paralelo. En una computadora de un slo CPU no es posible, pero la
programacin de la aplicacin es independiente de este hecho.
En muchos sentidos los hilos son como miniprocesos:
6
Cada hilo se ejecuta en forma estrictamente secuencial y tiene su propio contador de programa y una
pila para llevar un registro de su posicin.
Los hilos comparten el cpu de la misma forma que lo hacen los procesos, secuencialmente en tiempo
compartido.
Slo en un multiprocesador se pueden ejecutar realmente en paralelo.
Los hilos pueden crear hilos hijos.
Mientras un hilo est bloqueado se puede ejecutar otro hilo del mismo proceso.
Los distintos hilos de un proceso comparten un espacio de direcciones, el conjunto de archivos
abiertos, los procesos hijos, cronmetros, seales, etc.
Los hilos pueden tener distintos estados: en ejecucin, bloqueado, listo, terminado.
Un programa diseado adecuadamente y que utilice hilos debe funcionar bien:
En un nico cpu con hilos compartidos.
En un verdadero multiprocesador.
7
29 oct
Aspectos del Diseo de un Paquete de Hilos
Un conjunto de primitivas relacionadas con los hilos (ej.: llamadas a biblioteca) disponibles para los
usuarios se llama un paquete de hilos.
Respecto del manejo de los hilos se tienen hilos estticos e hilos dinmicos.
En un diseo esttico:
Se elige el nmero de hilos al escribir el programa o durante su compilacin.
Cada uno de ellos tiene asociada una pila fija.
Se logra simplicidad pero tambin inflexibilidad.
En un diseo dinmico:
Se permite la creacin y destruccin de los hilos durante la ejecucin.
La llamada para la creacin de hilos determina:
o El programa principal del hilo.
o Un tamao de pila.
o Una prioridad de planificacin, etc.
La llamada generalmente regresa un identificador de hilo que se usar en las posteriores llamadas
relacionadas al hilo.
Un proceso se inicia con un solo hilo y puede crear el nmero necesario de hilos. Hay hilos que una
vez que se inician nunca se eliminan
Los hilos pueden concluir por su cuenta al terminar su trabajo o por su eliminacin desde el exterior.
Los hilos comparten una memoria comn:
Contiene datos que los distintos hilos comparten.
El acceso generalmente se controla mediante regiones crticas por medio de semforos, monitores y
otras construcciones similares
9
1 nov
Implantacin de un Paquete de Hilos
Un paquete de hilos se puede implantar en el espacio del usuario o del ncleo.
Implantacin del paquete de hilos en el espacio del usuario:
El ncleo no sabe de su existencia.
El ncleo maneja procesos ordinarios con un nico hilo.
No requiere soporte de hilos por parte del
S. O.
Los hilos se ejecutan en la parte superior
de un sistema al tiempo de ejecucin, el
cual es un grupo de procedimientos que
manejan los hilos.
Cuando un hilo ejecuta una llamada al
sistema o cualquier accin que pueda
provocar su suspensin:
o Llama a un procedimiento del
sistema de tiempo de ejecucin.
o El procedimiento verifica si hay
que suspender al hilo, en cuyo
caso:
Almacena los registros del
hilo en una tabla.
Busca un hilo no bloqueado
para ejecutarlo.
Vuelve a cargar los registros de la mquina con los valores resguardados del nuevo hilo.
Tan pronto se intercambien el apuntador a la pila y el contador del programa, el nuevo
hilo vuelve a la vida
Las principales ventajas son:
o El intercambio de hilos es ms rpido que si se utilizaran los sealamientos al ncleo.
o Cada proceso puede tener su propio algoritmo adaptado de planificacin de hilos.
o Tienen una mejor escalabilidad para un nmero muy grande de hilos, ya que no afectan al
ncleo con tablas y bloques de control (pila).
Desventajas
Implantacin de llamadas al sistema con bloqueos. No se puede permitir que un hilo realice en realidad
una llamada al sistema porque esto bloqueara todos los hilos. Las llamadas se pueden modificar para que
no usen bloqueo pero no es bueno cambiar el SO.
10
11
3 nov
Hilos y RPC
Al iniciar un hilo servidor, S, ste exporta su interfaz al informarle de sta al ncleo; la interfaz define
los procedimientos que puede llamar, sus parmetros, etc.
Al iniciar un hilo cliente, C, ste importa la interfaz del ncleo:
Se le proporciona un identificador especial para utilizarlo en la llamada.
El ncleo sabe que C llamar posteriormente a S:
o Crea estructuras de datos especiales para prepararse para la llamada.
Una de las estructuras es una pila de argumentos compartida por C y S, que se asocia de manera
lectura / escritura en ambos espacios de direcciones.
Para llamar al servidor el cliente C:
Coloca sus argumentos en la pila compartida mediante el procedimiento normal de transferencia.
Hace un sealamiento al ncleo colocando un identificador especial en un registro.
El ncleo:
Detecta esto y deduce que es una llamada local.
Modifica el mapa de memoria del cliente para colocar ste en el espacio de direcciones del servidor.
Inicia el hilo cliente, al ejecutar el procedimiento del servidor.
La llamada se efecta de tal forma que:
Los argumentos se encuentran ya en su lugar:
o No es necesario su copiado u ordenamiento.
o La RPC local se puede realizar ms rpido de esta manera.
12
13
4 nov
3.3
Modelos de procesadores.
En un SD con varios procesadores, un aspecto fundamental del diseo es cmo se utilizan.
Los procesadores distribuidos se pueden organizar de varias formas:
Modelo de estacin de trabajo.
Modelo de la pila de procesadores.
Modelo hbrido.
3.3.1 De estacin 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 rgido en cada una de ellas.
Los usuarios tienen:
Una cantidad fija de poder de cmputo exclusiva.
Un alto grado de autonoma para asignar los recursos de su estacin de trabajo.
Uso de los discos en las estaciones de trabajo:
Sin disco:
Disco para paginacin y archivos de tipo borrador:
Disco para paginacin, archivos de tipo borrador y archivos binarios (ejecutables):
Disco para paginacin, borrador, binarios y cachs explcitos:
Sistema local de archivos completo:
14
15
16
5 nov
Uso de Estaciones de Trabajo Inactivas
La idea consiste en ordenar remotamente la ejecucin de procesos en estaciones de trabajo inactivas.
Los aspectos clave son:
Cmo encontrar una estacin de trabajo inactiva?
Cmo lograr que un proceso remoto se ejecute de forma transparente?
Qu ocurre si regresa el poseedor de la mquina?
Generalmente se considera que una estacin de trabajo est inactiva cuando se dan ambas condiciones:
Nadie toca el ratn o el teclado durante varios minutos.
No se ejecuta algn proceso iniciado por el usuario.
Los algoritmos para localizar las estaciones de trabajo inactivas se pueden dividir en dos categoras:
Controlados por el servidor.
Controlados por el cliente.
Algoritmos controlados por el servidor:
Cuando una estacin de trabajo est inactiva:
o Se convierte en un servidor potencial.
o Anuncia su disponibilidad:
Proporciona su nombre, direccin en la red y propiedades: Grabndolos en un
archivo o transmitindolos a las otras estaciones.
Se pueden dar situaciones de competencia entre distintos usuarios para acceder a la misma estacin
inactiva al mismo tiempo:
o Se deben detectar al ingresar el requerimiento.
o Slo progresa el primer requerimiento arribado.
o Se elimina a la estacin de la lista de inactivas.
o Quien hizo el llamado puede enviar su ambiente e iniciar el proceso remoto.
17
o
18
8 nov
3.3.2 De pila de procesadores.
El Modelo de la Pila de Procesadores
Se dispone de un conjunto de cpu que se pueden asignar dinmicamente a los usuarios segn la demanda.
Los usuarios no disponen de estaciones de trabajo sino de terminales grficas de alto rendimiento.
Llamamos a la tasa de entradas totales de solicitudes por segundo de todos los usuarios
combinados.
Llamamos a la tasa de procesamiento de solicitudes por parte del servidor.
Para una operacin estable debe darse que > :
o Se pueden permitir pequeos lapsos de tiempo en los que la tasa de entrada exceda a la de
servicio.
Llamamos T al promedio de tiempo entre la emisin de una solicitud y la obtencin de una
respuesta completa:
o T = 1 / ( - ).
o Cuando tiende a 0 (no hay carga), T no tiende a 0.
19
Supongamos que tenemos n multiprocesadores personales, cada uno con cierto nmero de cpu y
con su propio sistema de colas con tasas y y tiempo T:
o Si reunimos todas las cpu y formamos una sola pila de procesadores tendremos un slo sistema
de colas en vez de n colas ejecutndose en paralelo.
o La tasa de entrada ser n , la tasa de servicio ser n y el tiempo promedio de respuesta
ser:
T1 = 1 / (n - n ) = 1 / n ( - ) = T / n.
o Conclusin: si reemplazamos n pequeos recursos por uno grande que sea n veces ms
poderoso podemos reducir el tiempo promedio de respuesta n veces.
El modelo de pila es ms eficiente que el modelo de bsqueda de estaciones inactivas.
3.3.3 Hbrido.
20
9 nov
3.4
Asignacin de procesadores.
Se necesitan algoritmos para decidir cul proceso hay que ejecutar y en qu mquina.
Para el modelo de estaciones de trabajo:
Decidir cundo ejecutar el proceso de manera local y cundo buscar una estacin inactiva.
Para el modelo de la pila de procesadores:
Decidir dnde ejecutar cada nuevo proceso.
3.4.1 Modelos y algoritmos con sus aspectos de diseo e implantacin.
Modelos de Asignacin
Generalmente se utilizan las siguientes hiptesis:
Todas las mquinas son idnticas (o al menos compatibles en el cdigo); difieren a lo sumo en la
velocidad.
Cada procesador se puede comunicar con los dems.
Las estrategias de asignacin de procesadores se dividen en:
No migratorias:
o Una vez colocado un proceso en una mquina permanece ah hasta que termina.
Migratorias:
o Un proceso se puede trasladar aunque haya iniciado su ejecucin.
o Permiten un mejor balance de la carga pero son ms complejas.
Los algoritmos de asignacin intentan optimizar algo:
Uso de los cpu:
o Maximizar el nmero de ciclos de cpu que se ejecutan para trabajos de los usuarios.
o Minimizar el tiempo de inactividad de los cpu.
Tiempo promedio de respuesta:
o Minimizar no los tiempos individuales de respuesta sino los tiempos promedio de respuesta.
Tasa de respuesta:
21
5/1=5 70/60=1.6
Aspectos del Diseo de Algoritmos de Asignacin de Procesadores
Los principales aspectos son los siguientes:
Algoritmos deterministas vs. heursticos.
Algoritmos centralizados vs. distribuidos.
Algoritmos ptimos vs. subptimos.
Algoritmos locales vs. globales.
Algoritmos iniciados por el emisor vs. iniciados por el receptor.
Deterministas.- Son adecuados cuando se sabe anticipadamente todo acerca del comportamiento de los
procesos, esto generalmente no se da, aunque puede haber en ciertos casos aproximaciones estadsticas.
22
10 nov
Algoritmos iniciados por el emisor vs. iniciados por el receptor.
23
sncron
24
11 nov
Ejemplos de Algoritmos de Asignacin de Procesadores
Un Algoritmo Determinista Segn la Teora de Grficas
Es aplicable a sistemas donde se conocen:
Requerimientos de cpu y de memoria de los procesos.
Trfico promedio entre cada par de procesos.
Si el nmero de procesos supera al nmero de cpu:
Habr que asignar varios procesos al mismo cpu.
La asignacin deber minimizar el trfico en la red.
El sistema se puede representar en una grfica con pesos:
Cada nodo es un proceso.
Cada arco es el flujo de mensajes entre dos procesos.
El problema es encontrar la forma de dividir la grfica en subgrficas sujetas a restricciones (ej.: de cpu y
de memoria) (ver Figura 10.1 y Figura 10.2):
Los arcos que van de una subgrfica a la otra representan el trfico en la red, los que estn incluidos
en una subgrfica se pueden ignorar.
Cada subgrfica es una unidad de asignacin.
El algoritmo debe buscar unidades de asignacin fuertemente acopladas:
o Trfico intenso dentro de la unidad de asignacin.
o Trfico escaso entre unidades de asignacin.
25
Un Algoritmo Centralizado
Es un algoritmo heurstico que a diferencia del anterior no precisa informacin anticipadamente.
Es un algoritmo arriba-abajo (Mutka y Livny) centralizado porque un coordinador mantiene una tabla de
usos:
Contiene una entrada por estacin de trabajo (por usuario) inicializada en 0.
Cuando ocurren eventos significativos se envan al coordinador mensajes para actualizar la tabla.
Las decisiones de asignacin se basan en la tabla:
o Se toman cuando ocurren eventos de planificacin, tales como: se realiza una solicitud, se libera
un procesador, el reloj produce una marca de tiempo.
No se intenta maximizar el uso del cpu, otros mtodos pueden darle a un usuario todos los cpu con la
condicin de que los mantenga ocupados todo el tiempo.
Se procura otorgar a cada usuario una parte justa del poder de cmputo.
Cuando la mquina donde se crea un proceso decide que se debe ejecutar en otra parte:
o Le pide al coordinador de la tabla de usos que le asigne un procesador:
Si existe uno disponible y nadie ms lo desea, se otorga el permiso.
Si no, la solicitud se niega y se registra.
Si un usuario ejecuta procesos en mquinas de otros usuarios acumula puntos de penalizacin por
segundo, lo que se registra en la tabla de usos.
Si un usuario tiene solicitudes pendientes insatisfechas, se restan puntos de penalizacin.
Si no existen solicitudes pendientes y ningn procesador est en uso, la entrada de la tabla de usos se
desplaza un cierto nmero de puntos hacia el 0, hasta alcanzarlo.
El movimiento de puntos hacia arriba y abajo da nombre al algoritmo.
Un puntaje positivo en una entrada de la tabla de usos indica que la estacin de trabajo relacionada es un
usuario de los recursos del sistema.
Un puntaje negativo significa que precisa recursos.
Una puntuacin 0 es neutra.
La heurstica utilizada para la asignacin de procesadores es la siguiente:
Cuando un procesador se libera gana la solicitud pendiente cuyo poseedor tiene la puntuacin menor.
Un usuario que no ocupe procesadores y que tenga pendiente una solicitud durante mucho tiempo:
o Siempre vencer a alguien que utilice muchos procesadores.
o Se cumple con el principio de asignar la capacidad de manera justa.
26
12 nov
Un Algoritmo Jerrquico
El algoritmo anterior no se adapta bien a los sistemas de gran tamao, pues el nodo central se convierte en
un cuello de botella y en un nico punto de fallo.
Una solucin son los algoritmos jerrquicos que:
Mantienen la sencillez de los centralizados.
Se escalan mejor que los centralizados.
Un mtodo consiste en organizar a los procesadores en jerarquas lgicas independientes de la
estructura fsica:
Se establece un rbol jerrquico con distintos niveles.
Para cada grupo de mquinas hay una mquina administradora:
o Mantiene un registro de las mquinas ocupadas y las inactivas.
Cada procesador se comunica con un superior y un nmero reducido de subordinados:
o El flujo de informacin es controlable.
En caso de falla de un equipo con funciones jerrquicas:
Lo puede reemplazar un subordinado:
o La eleccin la pueden hacer los subordinados, los pares jerrquicos del equipo que fall o el
superior jerrquico del mismo.
Para disminuir la vulnerabilidad se puede tener en la cima del rbol jerrquico no uno sino un grupo de
equipos; si alguno del grupo falla los restantes eligen a un subordinado para integrar el grupo superior.
Las tareas se pueden crear en cualquier parte de la jerarqua y pueden requerir varios procesos, es decir
varios procesadores.
Cada administrador debe mantener un registro de sus equipos dependientes que estn disponibles.
Si el administrador que recibe una solicitud determina que no tiene suficientes procesadores disponibles,
transfiere la solicitud hacia arriba a su superior, quien tambin podra trasladarla hacia arriba nuevamente.
Si el administrador determina que s puede satisfacer la solicitud:
Divide la solicitud en partes y la distribuye a los administradores subordinados a l.
Los subordinados repiten esta operacin hasta llegar al nivel inferior.
Los procesadores se sealan como ocupados y el nmero de procesadores asignados se informa
hacia arriba.
Un importante problema consiste en que podra haber varias solicitudes en distintas etapas del algoritmo
de asignacin:
Puede conducir a estimaciones no actualizadas del nmero de procesadores disponibles (tambin
pudieron salir de servicio algunos de los considerados disponibles).
Podran presentarse situaciones de competencia, bloqueo, etc. en el intento de asignacin de
procesadores.
27
28
16 nov
3.5
Coplanificacin.
Planificacin en SD
Generalmente cada procesador hace su planificacin local (si tiene varios procesos en ejecucin)
independientemente de lo que hacen los otros procesadores.
La planificacin independiente no es eficiente cuando se ejecutan en distintos procesadores un grupo de
procesos relacionados entre s y con una gran interaccin.
29
3.6
Tolerancia a fallos.
Uso de redundancia
Redundancia de informacin.- Se envan bits de verificacin para recuperar los bits revueltos o faltantes.
Redundancia de tiempo.- Se hace una accin, y si se requiere, se repite (por ej. las transacciones atmicas)
Redundancia fsica.- Se agrega equipo adicional para permitir que el sistema tolere la prdida de algn
componente. Hay 2 formas de organizar esos equipos adicionales: Rplica activa y respaldo primario.
Rplica activa.- Implica un duplicado (2 ojos, 2 odos o 2 pulmones, varios rbitros en un partido,
aviones con 4 motores que funcionan slo con 3, etc.). Consideremos la Fig. 4.21(a), un circuito en que
las seales pasan por los dispositivos A, B y C en ese orden. Si uno falla, probablemente el resultado sera
incorrecto. En la Fig. 4.21(b) cada dispositivo se replica 3 veces. Despus de cada etapa aparece un
votante por triplicado. Cada votante es un circuito que tiene 3 entradas y 1 salida. Si 2 o 3 entradas son
iguales, la salida es igual a esa entrada. Si las 3 entradas son diferentes, la salida queda indefinida. Este
diseo se conoce como TRM (Redundancia modular triple).
30
31
17 nov
Respaldo primario.- El servidor primario siempre realiza la tarea, si falla, el respaldo ocupa su lugar, el
remplazo debe ocurrir de manera limpia y ser notado slo por el SO cliente, no por los programas de
aplicacin. Se usa mucho en la vida real. Presidente y suplente, piloto y copiloto, autos con llanta de
refaccin, computadoras con no break, etc.
Es ms sencillo que la rplica activa y se requieren menos mquinas, porque en cualquier instante se
necesitan un primario y un respaldo. Trabaja mal en fallas bizantinas.
3.7
SD de tiempo real.
Muchos Sistemas Operativos de tiempo real son construidos para aplicaciones muy especficas como
control de trfico areo, bolsas de valores, control de refineras. Tambin en el ramo automovilstico y de
la electrnica de consumo, las aplicaciones de tiempo real estn creciendo muy rpidamente. Otros
campos de aplicacin de los Sistemas Operativos de tiempo real son los siguientes:
Control de trenes.
Telecomunicaciones.
Sistemas de fabricacin integrada.
Produccin y distribucin de energa elctrica.
Control de edificios.
Sistemas multimedia.
Los Sistemas Operativos de tiempo real, cuentan con las siguientes caractersticas:
Se dan en entornos en donde deben ser aceptados y procesados gran cantidad de sucesos, la mayora
externos al sistema computacional, en breve tiempo o dentro de ciertos plazos.
Se utilizan en control industrial, conmutacin telefnica, control de vuelo, simulaciones en tiempo
real, aplicaciones militares, etc.
El objetivo es proporcionar rpidos tiempos de respuesta.
32
Procesa rfagas de miles de interrupciones por segundo sin perder un solo suceso.
Los procesos se activan tras la ocurrencia de sucesos, mediante una interrupcin.
Los procesos de mayor prioridad expropian recursos.
Por tanto generalmente se utiliza planificacin expropiativa basada en prioridades.
La gestin de memoria es menos exigente que en tiempo compartido, usualmente los procesos son
residentes en memoria.
La poblacin de procesos es esttica en gran medida.
Poco movimiento de programas entre almacenamiento secundario y memoria.
La gestin de archivos se orienta ms a velocidad de acceso que a utilizacin eficiente del recurso.
33