Sos Distribuido

UNIVERSIDAD VALLE DEL GRIJALVA CAMPUS PICHUCALCO
SISTEMAS OPERATIVOS DISTRIBUIDO

PAULINO HERNANDEZ HERNANDEZ
06/10/12
T I T U L A R : ING. JESUS GAMALIEL HERNANDEZ CANO
Sistemas operativos distribuidos
INDICE
TEMAS INTRODUCCION 3. COORDINACIN DISTRIBUIDA. 3.1 Relojes.. 3.2 Ordenacin.. 3.3 Exclusin mutua.. 3.4 Transacciones atmicas. 3.5 Bloqueos mutuos 3.6 Algoritmos de sincronizacin.. 4. PROCESOS Y PROCESADORES 4.1 Hilos. 4.2 Modelos de sistemas. 4.3 Asignacin de procesadores.. 4.4 Planificacin 4.5 Tolerancia a fallas.. 4.6 Sistemas de tiempo real CONCLUSIN. BIBLIOGRAFA.. PAGINA 3 4 4 10 14 16 16 18 22 22 23 26 28 29 34 36 37
Paulino Hernndez Hernndez
Pgina 2
INTRODUCCION
Un sistema operativo es un conjunto de sistemas y programas que actan como intermediario entre en usuario y el hardware de la computadora, el propsito general del sistema operativo es proporcionar un entorno en el cual el usuario pueda ejecutar sus programas. El propsito principal de un sistema operativo es lograr que el sistema de cmputo se utilice de manera ptima, y el objetivo secundario es que el hardware del computador se emplee de manera eficiente. Existen diferentes tipos de sistema operativo entre los que se encuentran los sistemas operativos distribuidos los cuales los estudiaremos mas adelante. Los sistemas operativos funcionan igual que un sistema operativo normal con la diferencia de que este funciona de manera distribuida. Su principal funcin es facilitar el acceso y administrar los recursos distribuidos en la red. Todo lo referido al sistema operativo distribuido sern estudiados en el siguiente apartado esperando que sea de gran utilidad.
Pgina 3
3. COORDINACIN DISTRIBUIDA
3.1 RELOJES
Sincronizacin de Relojes Generalmente los algoritmos distribuidos tienen las siguientes propiedades:

La informacin relevante se distribuye entre varias mquinas. Los procesos toman las decisiones solo con base en la informacin disponible en forma local.
Debe evitarse un nico punto de fallo en el sistema. No existe un reloj comn o alguna otra fuente precisa del tiempo global.
Los primeros tres puntos indican que es inaceptable reunir toda la informacin en un solo lugar para su procesamiento, pero lograr la sincronizacin sin centralizacin requiere hacer las cosas distintas al caso de los sistemas operativos tradicionales. El ltimo punto tambin es crucial:

En un sistema centralizado el tiempo no es ambiguo. En un sistema distribuido no es trivial poner de acuerdo a todas las mquinas en la hora.
Se requiere un acuerdo global en el tiempo, pues la falta de sincronizacin en los relojes puede ser drstica en procesos dependientes del tiempo.
La pregunta es si es posible sincronizar todos los relojes en un sistema distribuido. Relojes Lgicos Las computadoras poseen un circuito para el registro del tiempo conocido como dispositivo reloj. Es un cronmetro consistente en un cristal de cuarzo de precisin sometido a una tensin elctrica que:

Oscila con una frecuencia bien definida que depende de: Al forma en que se corte el cristal. El tipo de cristal. La magnitud de la tensin.
Pgina 4
A cada cristal se le asocian dos registros:

Registro contador. Registro mantenedor. Cada oscilacin del cristal decrementa en 1 al contador. Cuando el contador llega a 0: Se genera una interrupcin. El contador se vuelve a cargar mediante el registro mantenedor. Se puede programar un cronmetro para que genere una interrupcin x veces por segundo.
Cada interrupcin se denomina marca de reloj.
Para una computadora y un reloj:

No interesan pequeos desfasajes del reloj porque: Todos los procesos de la mquina usan el mismo reloj y tendrn consistencia interna.
Importan los tiempos relativos.
Para varias computadoras con sus respectivos relojes:
Es imposible garantizar que los cristales de computadoras distintas oscilen con la misma frecuencia.
Habr una prdida de sincrona en los relojes (de software) , es decir que tendrn valores distintos al ser ledos.
La diferencia entre los valores del tiempo se llama distorsin del reloj y podra generar fallas en los programas dependientes del tiempo. Lamport demostr que la sincronizacin de relojes es posible y present un algoritmo para lograrlo. Lamport seal que la sincronizacin de relojes no tiene que ser absoluta:
Si 2 procesos no interactan no es necesario que sus relojes estn sincronizados.
Generalmente lo importante no es que los procesos estn de acuerdo en la hora, pero s importa que coincidan en el orden en que ocurren los eventos.
Pgina 5
Para ciertos algoritmos lo que importa es la consistencia interna de los relojes:

No interesa su cercana particular al tiempo real (oficial). Los relojes se denominan relojes lgicos.
Los relojes fsicos son relojes que:

Deben ser iguales (estar sincronizados). No deben desviarse del tiempo real ms all de cierta magnitud.
Para sincronizar los relojes lgicos, Lamport defini la relacin ocurre antes de (happens-before):
Si a y b son eventos en el mismo proceso y a ocurre antes de b, entonces a > b es verdadero. Ocurre antes de es una relacin transitiva: Si a > b y b > c, entonces a > c. Si dos eventos x e y estn en procesos diferentes que no intercambian mensajes, entonces x > y no es verdadero, pero tampoco lo es y > x:
Se dice que son eventos concurrentes.
Necesitamos una forma de medir el tiempo tal que a cada evento a, le podamos asociar un valor del tiempo C(a) en el que todos los procesos estn de acuerdo:

Se debe cumplir que: Si a > b entonces C(a) < C (b). El tiempo del reloj, C, siempre debe ir hacia adelante (creciente), y nunca hacia atrs (decreciente).
El algoritmo de Lamport asigna tiempos a los eventos. Consideramos tres procesos que se ejecutan en diferentes mquinas, cada una con su propio reloj y velocidad.
El proceso 0 enva el mensaje a al proceso 1 cuando el reloj de 0 marca 6. El proceso 1 recibe el mensaje a cuando su reloj marca 16. Si el mensaje acarrea el tiempo de inicio 6, el proceso 1 considerar que tard 10 marcas de reloj en viajar.
Pgina 6

El mensaje b de 1 a 2 tarda 16 marcas de reloj. El mensaje c de 2 a 1 sale en 60 y llega en 56, tardara un tiempo negativo, lo cual es imposible. El mensaje d de 1 a 0 sale en 64 y llega en 54. Lamport utiliza la relacin ocurre antes de: Si c sale en 60 debe llegar en 61 o en un tiempo
posterior.
Cada
mensaje
acarrea
el
tiempo de envo, de acuerdo con el reloj del emisor.
Cuando un mensaje llega y el reloj del receptor muestra un valor anterior al tiempo en que se envi el mensaje:
El receptor adelanta su reloj para que tenga una unidad ms que el tiempo de envo.
Este algoritmo cumple nuestras necesidades para el tiempo global, si se hace el siguiente agregado:

Entre dos eventos cualesquiera, el reloj debe marcar al menos una vez. Dos eventos no deben ocurrir exactamente al mismo tiempo.
Con este algoritmo se puede asignar un tiempo a todos los eventos en un sistema distribuido, con las siguientes condiciones:

Si a ocurre antes de b en el mismo proceso, C(a) < C (b). Si a y b son el envo y recepcin de un mensaje, C(a) < C (b). Para todos los eventos a y b, C(a) es distinto de C (b).
Pgina 7
Relojes Fsicos El algoritmo de Lamport proporciona un orden de eventos sin ambigedades, pero :
Los valores de tiempo asignados a los eventos no tienen porqu ser cercanos a los tiempos reales en los que ocurren.
En ciertos sistemas (ej.: sistemas de tiempo real ), es importante la hora real del reloj:
Se precisan relojes fsicos externos (ms de uno). Se deben sincronizar: Con los relojes del mundo real. Entre s.
La medicin del tiempo real con alta precisin no es sencilla. Desde antiguo el tiempo se ha medido astronmicamente. Se considera el da solar al intervalo entre dos trnsitos consecutivos del sol, donde el trnsito del sol es el evento en que el sol alcanza su punto aparentemente ms alto en el cielo. El segundo solar se define como 1 / 86.400 de un da solar. Como el perodo de rotacin de la tierra no es constante, se considera el segundo solar promedio de un gran nmero de das. Los fsicos definieron al segundo como el tiempo que tarda el tomo de cesio 133 para hacer 9.192.631.770 transiciones: Se tom este nmero para que el segundo atmico coincida con el segundo solar promedio de 1958. La Oficina Internacional de la Hora en Pars (BIH) recibe las indicaciones de cerca de 50 relojes atmicos en el mundo y calcula el tiempo atmico internacional (TAI). Como consecuencia de que el da solar promedio (DSP) es cada vez mayor, un da TAI es 3 mseg menor que un DSP:
La BIH introduce segundos de salto para hacer las correcciones necesarias para que permanezcan en fase:
Pgina 8

El sistema de tiempo basado en los segundos TAI. El movimiento aparente del sol. Surge el tiempo coordenado universal (UTC).
El Instituto Nacional del Tiempo Estndar (NIST) de EE. UU. Y de otros pases:

Operan estaciones de radio de onda corta o satlites de comunicaciones. Transmiten pulsos UTC con cierta regularidad establecida (cada segundo, cada 0,5 mseg, etc.).
Se deben conocer con precisin la posicin relativa del emisor y del receptor: Se debe compensar el retraso de propagacin de la seal. Si la seal se recibe por mdem tambin se debe compensar por la ruta de la seal y la velocidad del mdem.
Se dificulta la obtencin del tiempo con una precisin extremadamente alta.
La sincronizacin no tiene por qu ser exacta, y bastar con que sea aproximadamente igual en todos los ordenadores. Hay que tener en cuenta, eso s, el modo de actualizar la hora de un reloj en particular. Es fundamental no retrasar nunca la hora, aunque el reloj adelante. En vez de eso, hay que ralentizar la actualizacin del reloj, frenarlo, hasta que alcance la hora aproximadamente. Existen diferentes algoritmos de actualizacin de la hora, tres de ellos se exponen brevemente a continuacin: Algoritmo de Lamport Tras el intento de sincronizar todos los relojes, surge la idea de que no es necesario que todos los relojes tengan la misma hora exacta, sino que simplemente mantengan una relacin estable de forma que se mantenga la relacin de qu suceso ocurri antes que otro suceso cualquiera. Este algoritmo se encarga exclusivamente de mantener el orden en que se suceden los procesos. En cada mensaje que se enva a otro ordenador se incluye la hora. Si el receptor del mensaje tiene una hora anterior a la indicada en el mensaje, utiliza la hora recibida incrementada en uno para actualizar su propia hora.
Pgina 9
Algoritmo de Cristian Consiste en disponer de un servidor de tiempo, que reciba la hora exacta. El servidor se encarga de enviar a cada ordenador la hora. Cada ordenador de destino slo tiene que sumarle el tiempo de transporte del mensaje, que se puede calcular de forma aproximada. Algoritmo de Berkeley La principal desventaja del algoritmo de Cristian es que todo el sistema depende del servidor de tiempo, lo cual no es aceptable en un sistema distribuido fiable. El algoritmo de Berkeley usa la hora de todos los ordenadores para elaborar una media, que se reenva para que cada equipo actualice su propia hora ralentizando el reloj o adoptando la nueva hora, segn el caso.
3.2 ORDENACIN
La ordenacin temporal de sucesos es fundamental para la operacin de la mayora de los algoritmos distribuidos de exclusin mutua e interbloqueo. La carencia de un reloj comn o de un medio de sincronizar los relojes locales es por lo tanto una restriccin importante. El problema puede expresarse de la manera sigte. Se desea poder decir si el suceso a del sistema i ocurri antes(o despus) del suceso b en el sistema j y ser capaz de llegar de forma coherente a esta conclusin en todos los sistemas de la red. Desgraciadamente esta afirmacin no es precisa por dos razones: En primer lugar, puede producirse un retardo entre el acontecimiento real de un proceso y el momento en que se observa en otro sistema. En segundo lugar, la falta de sincronizacin lleva a un desacuerdo en la lectura de los relojes de lo sistemas diferentes. Para superar estas dificultades Lamport propuso un mtodo como registro de tiempo, o marcas de tiempo , que sirve para ordenar los sucesos en un sistema distribuido sin utilizar relojes fsicos (estrictamente sincronizados). Esta tcnica se llama Happens before: ocurre antes de; se trata de la importancia respecto del orden en que ocurran los eventos y no del tiempo, es decir Como y no cuando, es tan diferente y efectiva que se usa en la gran mayora de los algoritmos de exclusin mutua e interbloqueo. Para
Paulino Hernndez Hernndez Pgina 10
comenzar, hace falta optar por una definicin del trmino suceso. En el fondo, hay que preocuparse de las acciones que se producen en un sistema local, como la entrada o salida de procesos de su seccin critica. Sin embrago, en un sistema distribuido la forma en que los procesos interaccionan es mediante mensajes. Por lo tanto, parece lgico asociar los sucesos con los mensajes. Un suceso local puede limitarse a un simple mensaje; es decir, un proceso debe enviar un mensaje a todos los dems procesos cuando desee entrar en su seccin crtica o cuando salga de ella (inclusive al mismo). Para evitar la ambigedad, se asociaran los sucesos solo con el envo de mensajes, no con la recepcin. As, cada vez que un proceso transmita un mensaje, se definir el suceso correspondiente al momento en que el mensaje sale del proceso. El esquema de marcas de tiempo tiene la finalidad de ordenar los sucesos consistentes en la transmisin de los mensajes. Cada sistema i de la red mantiene un contador local C i que funciona como un reloj. Cada vez que un sistema transmita un mensaje, incrementar su reloj en 1 (antes de transmitir); el mensaje se enva de la forma: (m, T i, i) donde m= contenido del mensaje; T= marca del tiempo del mensaje,
puesta a C i; i= identificador numrico del nodo Cuando se recibe el mensaje, el sistema receptor j pone su reloj a uno ms que el mximo de su valor actual y la marca de tiempo entrante: C j <1 mx. [C j, T i ] En cada nodo, la ordenacin de sucesos queda determinada por las reglas siguientes. Para los mensajes x del nodo i e y del nodo j, se dice que x precede a y si cumple una de las siguientes condiciones: Si T i<T j Si T i = T j e i<j El tiempo asociado con el suceso dcada mensaje es la marca de tiempo que acompaa al mensaje, mientras que la ordenacin de estos tiempos se determina por las dos reglas anteriores, en ellas, dos sucesos de mensajes con las mismas marcas de tiempo se ordenan por sus nodos. Como la aplicacin de estas reglas es independiente del nodo, este mtodo evita cualquier problema de deriva
entre los diversos relojes de los procesos comunicantes que implican retardo. Un ejemplo del funcionamiento de este algoritmo ofrece la fig. Que sigue, donde aparecen tres nodos, cada uno de los cuales est representado por un proceso que controla el algoritmo de marcas de tiempo. El proceso P 1 comienza con un valor de reloj de 0. Para transmitir el mensaje a, incrementa su reloj y transmite (a, 1,1), donde el primer valor numrico es la marca de tiempo y el segundo es la identidad del nodo. Este mensaje es recibido por los procesos de los nodos 2 y 3. En ambos casos, los relojes locales tienen un valor 0 y se ponen a 2=1+max [0,1]. P 2 emite el siguiente mensaje x, incrementado previamente su reloj hasta 3. Al recibir este mensaje, P 1 y P 3 deben incrementar sus relojes hasta 4, entonces, P 1 emite el mensaje b y P 3 emite el mensaje j aproximadamente al mismo tiempo y con la misma marca de tiempo. Por el principio de ordenacin, esto no causa confusin. Despus de que todos estos suceso hayan tenido lugar, la ordenacin de los mensajes permanece igual en todos los nodos, es decir {a, x, b, j}. El algoritmo funciona a pesar de las diferencias en tiempos de transmisin entre cada pareja de sistemas, como muestra en la fig. Anterior, donde P 1 y P 4 aparecen emitiendo mensajes con la misma marca de tiempo. El mensaje de P 1 llega antes que el de P 4 al nodo 2, pero ms tarde que el de P 4 al nodo 3, Sin embargo, despus de que se
reciban todos los mensajes en todos los nodos, la ordenacin de los sucesos de mensaje es la misma en todos los nodos, es decir {a, q}. Ntese que la ordenacin por este sistema no tiene por qu coincidir con la secuencia real de tiempo. Para los algoritmos basados en este esquema de marcas de tiempo, en realidad no es importante que suceso ocurre primero, solo importa que todos los procesos que implementen el algoritmo estn de acuerdo en la ordenacin que se hace sobre los sucesos. En estos dos ejemplos vistos recientemente, cada mensaje se enva desde un proceso hacia todos los dems. Si algunos mensajes no se envan de esta forma, algunos nodos no recibirn todos los mensajes del sistema, entonces existe un conjunto de ordenacin parcial y, por lo tanto, es imposible que todos los nodos dispongan de la misma ordenacin de mensajes. Sin embargo la preocupacin principal es el uso de marcas de tiempo en los algoritmos distribuidos para la exclusin mutua y la deteccin del interbloqueo. En tales algoritmos, un proceso suele mandar un mensaje (con su marca de tiempo) a todos los dems procesos, emplendose las marcas de tiempo para determinar cmo se procesan los mensajes.
Con el algoritmo de Lamport la exclusin mutua queda garantizada. En conclusin, debe recibir respuestas de todos los procesos que haya.
Entonces cuando un proceso sale de la regin critica libera la cola (borra todos los procesos encolados, por lo tanto no hay inanicin de procesos porque estar todos en un cola, en algn momento sern atendidos, a medida que c/ proceso pueda entrar a ejecutar la regin Critica. Con este algoritmo hay muchas mensajes (de solicitud y confirmacin) que implican grandes tiempos de espera y por tanto sobrecarga al sistema, adems de tener n puntos de fallo.
Este algoritmo requiere 3* (n-1) mensajes para una solicitud de entrada.
Existe un algoritmo realizado por Ricart que mejora al de Lamport, reduciendo el nro de mensajes a 2 * (n-1). Algoritmo de Ricart.
Cuando un proceso quiere entrar en su seccin critica, enva un mensaje de

Pgina 13
solicitud, a todos los dems procesos. (n-1)

El proceso que recibe el mensaje se encuentra en 1 de estos 3 estados : No quiere entrar en su seccin crtica. Enva mensaje de aceptacin. esta en ese momento en su seccin critica. Demora un mensaje de aceptacin hasta que salga de su seccin crtica.
Tiene una peticin pendiente de entrada en su seccin crtica. Copara la marca de la peticin con la suya propia. Si su marca de peticin es superior a la que ha recibido en el mensaje de peticin no atiende la peticin hasta que no ah salido de su seccin critica, pero si es inferior, enva un mensaje de aceptacin y espera su turno.
Un proceso para entrar en su seccin critica necesita n-1 mensajes de aceptacin., si los recibe, es que todos estn de acuerdo.
Cuando sale de su seccin crtica libera el recurso enviando mensajes a cada peticin pendiente.
El algoritmo cumple la exclusin mutua asegurando que no se producen interbloqueos ni tampoco inanicin.
3.3 EXCLUSIN MUTUA

Si varios usuarios accesan concurrentemente a un recurso compartido, las acciones que realice el usuario sin que le interese al resto de los usuarios, debe ser instantneo e indivisible. El problema de la exclusin mutua en sistemas distribuidos surge cuando se accesa concurrentemente a recursos compartidos por varios nodos de procesamiento. En sistemas de una sola computadora, el estado de un recurso compartido y el estado de un usuario es ms accesible por la existencia de una memoria compartida y se pueden implementar fcilmente soluciones a la exclusin mutua, haciendo uso de variables compartidas como los semforos. Sin embargo, en sistemas distribuidos los recursos compartidos y los usuarios pueden estar distribuidos y no existe una memoria compartida entre ellos; consecuentemente, los enfoques basados en variables compartidas no son aplicables a los sistemas distribuidos, en su lugar; se deben utilizar enfoques basados en el paso de mensajes. El problema de la exclusin mutua resulta ms
compleja en los sistemas distribuidos, debido a los retardos impredecibles de los mensajes. Cuando un proceso requiere leer o actualizar ciertas estructuras de datos compartidas, primero entra a una seccin crtica (SC) para lograr la exclusin mutua asegurndose que ningn otro proceso utilice las mismas estructuras al mismo tiempo. Se han propuesto varios algoritmos para lograr exclusin mutua en sistemas distribuidos, los cuales tienden a diferenciarse por su topologa y la cantidad de informacin mantenida en los nodos de procesamiento. Los algoritmos pueden agruparse dentro de los dos siguientes grupos:
Algoritmos no basados en paso de mensajes. Estos algoritmos requieren dos o ms rondas sucesivas de mensajes entre los nodos. Se basan en una aseveracin porque un nodo puede entrar a su seccin crtica de procesamiento (SC) cuando una aseveracin en sus variables se vuelve verdadera. Se forza la exclusin mutua porque la aseveracin es verdadera en un solo nodo en un determinado momento.
Algoritmos basados en paso de mensajes. En estos algoritmos, un token nico (tambin llamado mensaje de privilegio) se comparte en todos los nodos. Se permite que un nodo entre a su seccin crtica (SC) si posee al token y lo mantiene hasta que termine la ejecucin de su SC.
Estos algoritmos de exclusin mutua tienen el objetivo de garantizar que solo una peticin pueda entrar a la seccin crtica de un nodo y se deben de considerar las siguientes caractersticas:
Los nodos no deben esperar indefinidamente a mensajes que probablemente no llegaron (interbloqueo distribuido).
Cada nodo debe tener un tiempo finito para la ejecucin de una seccin crtica. Las peticiones deben ejecutarse en el orden en que se hicieron, o el orden en que arribaron al sistema.
Un algoritmo es tolerante a fallas si al momento de la recuperacin cuando ocurra una, este pueda continuar con su funcin.
El funcionamiento de los algoritmos de exclusin mutua puede expresarse por las siguientes medidas:

El nmero de mensajes necesarios para una SC. El retardo de sincronizacin, que representa el tiempo requerido despus de que un nodo termina su SC y antes de que otro nodo inicie una SC.
El tiempo de respuesta. Es el intervalo de tiempo que una solicitud espera para que se ejecute una SC, despus del envo del mensaje de solicitud.
La ejecucin en el sistema, que es la razn a la que el sistema ejecuta la peticin para la SC.
3.4 TRANSACCIONES ATMICAS

Es un mtodo de sincronizacin a alto nivel, que a diferencia de los mtodos revisados hasta el momento, no ocupa al programador en los aspectos de exclusin mutua, prevencin de bloqueos y recuperacin ante fallos. Por el contrario, este mtodo orienta el esfuerzo del programador a los verdaderos problemas y esencia de la sincronizacin de sistemas distribuidos. El concepto de transacciones atmicas consiste en garantizar que todos los procesos que conforman una transaccin deben ejecutarse en forma completa y satisfactoria. De producirse falla en alguno de los procesos, toda la transaccin falla, revirtindose la misma y procedindose a su reinicio.
3.5 BLOQUEOS MUTUOS

El bloqueo mutuo es ms serio que la inanicin (posposicin indefinida) porque afecta ms de un trabajo (la totalidad del sistema, eventualmente). Los bloqueos mutuos eran poco frecuentes en los primeros sistemas porque los trabajos incluan una lista completa de los recursos que necesitaban para ejecutarse y el sistema operativo se aseguraba que estos estuvieran libres y asignados antes de poner, al trabajo, en la cola de LISTOS. - Los bloqueos mutuos se hicieron ms frecuentes con los sistemas interactivos, porque estos son ms flexibles y mejoran el uso de recursos al compartirlos en forma dinmica.
Caractersticas de bloqueo mutuo - Exclusin mutua: solo un proceso por vez puede usar el recurso (solo una persona tiene acceso a un escaln). - Retencin y espera: debe existir un proceso que est reteniendo por lo menos un recurso y est esperando adquirir recursos adicionales que en ese momento estn siendo retenidos por otro proceso (la persona se empea en no retirarse). - No apropiacin: un recurso solo puede ser liberado voluntariamente por el proceso que lo est reteniendo, una vez que dicho proceso ha completado su tarea (cada escaln est asignado al que sube, o al que baja, tanto tiempo como sea necesario). - Espera circular: (cada persona espera que la otra libere el escaln) debe existir un conjunto {P0, P1,, P0} de procesos en espera, tal que P0 est esperando un recurso que est retenido por P1, P1 est esperando un recurso que est retenido por P2,, Pn1 est esperando por un recurso retenido por Pn, y Pn est esperando por un recurso retenido por P0. Mtodos para manejar bloqueos mutuos - Podemos utilizar un protocolo para asegurar que el sistema nunca entrar en un estado de bloqueo mutuo. - Podemos permitir que el sistema entre en un estado de bloqueo mutuo y luego hacer una recuperacin. - Podemos ignorar el problema y pretender que los bloqueos mutuos nunca ocurren en el sistema; usado por la mayora de los sistemas operativos, incluyendo a UNIX Prevencin de bloqueos mutuos - Espera Circular.- Imponer un ordenamiento total de todos los tipos de recursos (numerarlos: impresora = 1, disco = 2, etc.), y requerir que cada proceso solicite
sus recursos en orden creciente de enumeracin (ordenamiento jerrquico que obliga a anticipar el orden en que utilizara los recursos). - No Apropiacin.- Si un proceso que est reteniendo algunos recursos solicita otro recurso que no le puede ser asignado inmediatamente, entonces todos los recursos que actualmente son retenidos son apropiados (se liberan
implcitamente). Los recursos apropiados se agregan a la lista de recursos que el proceso est esperando. El proceso se reiniciar solamente cuando pueda volver a obtener sus antiguos recursos, as como los nuevos que est solicitando. Evitacin de bloqueos mutuos Los algoritmos de prevencin de bloqueos mutuos funcionan restringiendo la
forma en que pueden hacerse las solicitudes; una accin colateral al usar estos algoritmos est una baja utilizacin de dispositivos, reduccin del sistema e inanicin de procesos. Deteccin de bloqueos mutuos Los bloqueos mutuos se pueden detectar, elaborando graficas de recursos dirigidos y buscando ciclos, este algoritmo se puede ejecutar siempre que sea apropiado: cuando la produccin se ha deteriorado o cuando se queje un usuario o cada hora, etc.
3.6 ALGORITMOS DE SINCRONIZACION

Si una mquina tiene un receptor WWV, entonces el objetivo es hacer que todas las mquinas se sincronicen con ella. Si ninguna mquina tiene receptores WWV, entonces cada mquina lleva el registro de su propio tiempo y el objetivo es mantener el tiempo de todas las mquinas tan cercano sea posible. Algoritmo de Cristian Este algoritmo es adecuado para los sistemas en los que una mquina tiene un receptor WWV y el objetivo es hacer que todas las mquinas se sincronicen con
Pgina 18
ella. Llamaremos a la mquina con el receptor WWV un servidor del tiempo . En forma peridica, en un tiempo que no debe ser mayor que d /2 r segundos, cada mquina enva un mensaje al servidor para solicitar el tiempo actual. Esa mquina responde tan pronto como puede con un mensaje que contiene el tiempo actual, C UTC. Como primera aproximacin,
cuando el emisor obtiene la respuesta, puede hacer que su tiempo sea C UTC . Sin embargo, este algoritmo tiene dos problemas, uno mayor y otro menor. El problema mayor es que el tiempo nunca debe correr hacia atrs. Si el reloj del emisor es ms rpido, C UTC ser menor que el valor actual de C del emisor. El simple traslado de C UTC podra provocar serios problemas, tales como tener un archivo objeto compilado justo despus del cambio de reloj y que tenga un tiempo anterior al del archivo fuente, modificando justo antes del cambio del reloj. Tal cambio se debe introducir de manera gradual. Una forma es la siguiente: Supongamos que el cronmetro se ajusta para que genere 100 interrupciones por segundo Lo normal sera que cada interrupcin aadiera 10 milisegundos al tiempo. Al reducir la velocidad, la rutina de interrupcin slo aade 9 milisegundos cada vez, hasta que se haga la correccin. De manera similar, el reloj se puede adelantar de manera gradual, sumando 11 milisegundos en cada interrupcin en vez de saltar hacia delante de una vez. El problema menor es que el tiempo que tarda el servidor en responder al emisor es distinto de cero. Peor an, este retraso puede ser de gran tamao y vara con la carga de la red. La forma de enfrentar este problema por parte de Cristian es intentar mediarlo. Es muy fcil para el emisor registrar de manera precisa el intervalo de inicio, T 0, como el tiempo final, T 1, se miden con el mismo reloj, por lo que el intervalo ser relativamente preciso, aunque el reloj del emisor est alejado de UTC por una magnitud sustancial. En ausencia de otra informacin, la mejor estimacin del tiempo de propagacin del mensaje es de ( T 1 -T 0 /2 ). Al llegar la respuesta, el valor en el mensaje puede ser incrementado por esta cantidad para dar una estimacin del tiempo actual del servidor. Si se conoce el tiempo mnimo de propagacin terico, se pueden calcular otras propiedades de la estimacin del tiempo. Es estimacin se puede
mejorar si se conoce con cierta aproximacin el tiempo que tarda el servidor del tiempo en manejar la interrupcin y procesar el mensaje recibido. Llamaremos al tiempo para el manejo de interrupcin I . Entonces la cantidad del tiempo desde T 0 hasta T 1 dedicada a al propagacin del mensaje es T 1 -T 0 -I, por lo que una mejor estimacin del tiempo de propagacin en un sentido es la mitad de esta cantidad. Para mejorar la precisin, Cristian sugiri hacer no una medicin, sino varias. Cualquier medicin en la que T 1 -T 0 exceda cierto valor lmite se descarta, por ser considerada vctima del congestionamiento en la red por tanto no confiable. Las estimaciones obtenidas de las dems pruebas se pueden promediar para obtener mejor valor. Otra alternativa es que el mensaje que regrese ms rpido se considere como el ms preciso, pues supuestamente encontrara menos trfico y por lo tanto sera el ms representativo del tiempo de propagacin puro. Algoritmo de Berkeley En el algoritmo de Cristian, el servidor de tiempo es pasivo. En este caso, el servidor de tiempo (en realidad, un demonio para el tiempo) est activo y realiza un muestreo peridico de todas las mquinas para preguntarles el tiempo. Con base en las respuestas, calcula un tiempo promedio y le indica a todas las dems mquinas que avancen su reloj a la nueva hora o que disminuyan la velocidad del mismo hasta lograr cierta reduccin especfica. Este mtodo es adecuado para un sistema donde no exista un receptor de WWV. La hora del demonio para el tiempo debe ser establecida en forma manual por el operador, de manera peridica. Algoritmos con promedio Los dos mtodos anteriores son muy centralizados, con las desventajas usuales. Una clase de algoritmos centralizados trabaja al dividir el tiempo en intervalos de resincronizacin de longitud fsica. Al inicio de cada intervalo, cada mquina transmite el tiempo actual segn su reloj. Puesto que los relojes de las diversas mquinas no funcionan con exactamente la misma velocidad, estas transmisiones no ocurrirn en forma simultnea. Despus de que una mquina transmite su hora, inicia un cronmetro local para reunir las dems transmisiones que lleguen
en cierto intervalo S. Cuando llegan todas las transmisiones, se ejecuta un algoritmo para calcular una nueva hora para ellos. El algoritmo ms sencillo consiste en promediar los valores de todas las dems mquinas. Una ligera variacin es descartar primero los m valores ms grandes y los m valores ms pequeos, y promediar el resto. El hecho de descartar los valores ms extremos se puede considerar como autodefensa contra m relojes fallidos que envan mensajes sin sentido. Otra variacin intenta corregir a cada mensaje al aadir una estimacin del tiempo de propagacin desde la fuente. Esta estimacin se puede hacer a partir de la topologa conocida de la red o al medir el tiempo que tardan en regresar ciertos mensajes de prueba. Varias fuentes externas de tiempo Para los sistemas que requieren sincronizacin en extrema precisa con UTC, es posible equiparlos con varios receptores de WWV, GEOS o algunas otras fuentes de UTC. Sin embargo, debido a la imprecisin inherente en la propia fuente de tiempo, as como a las fluctuaciones en la ruta de la seal, lo mejor que puede hacer el sistema operativo es establecer un rango (intervalo de tiempo) en el que caiga UTC. En general, las distintas fuentes de tiempo producirn distintos mrgenes, lo que requiere un acuerdo entre las mquinas conectadas a ellas. Para lograr este acuerdo, cada procesador con fuente UTC puede transmitir su rango en forma peridica; digamos, en el preciso inicio de cada minuto UTC. Ninguno de los procesadores obtendr los paquetes de tiempo en forma instantnea. Peor an, el retraso entre la transmisin y recepcin depende de la distancia del cable y el nmero de compuertas que deben atravesar los paquetes, que es diferente para cada pareja (fuente de UTC, procesador). En fin pueden jugar un papel otros factores.
Pgina 21
4. PROCESOS Y PROCESADORES
Un proceso . Son todos o todas las actividades o programas compilados que se encuentran guardados en una memoria. Un procesador. Es el dispositivo de hardware que se encarga de ejecutar los procesos.
4.1 HILOS
Hilos de Procesos (Threads) Hoy en da los sistemas operativos pueden soportar mltiples hilos de control dentro de un proceso. Dos caractersticas notorias en los hilos de procesos es que comparten un nico espacio de direcciones, y a su vez, simulan un ejectese de mltiples procesos independientes como si fuera en paralelo. Solo en una maquina que tenga multiprocesador se pueden ejecutar realmente procesos en paralelo. Los hilos se pueden colocar en cuatro estados:

En ejecucin, cuando el proceso se est ejecutando. Bloqueado, cuando un proceso depende de un recurso critico. Listo, cuando puede utilizarse nuevamente. Terminado, cuando culmina su tarea.
Implantacin de un Paquete de Hilos Existen dos formas de implantar los hilos: En el usuario Cuando se realiza la instalacin de los paquetes a nivel de usuario, el ncleo no debe saber de su existencia, por lo cual el ncleo solo va a manejar un nico hilo. Los hilos se ejecutan en el sistema por tiempo de ejecucin en grupos de procedimientos. En el caso que el sistema o procedimiento requiera suspender un
hilo dentro de su manejo, almacena los registros del hilo en una tabla, busca los no bloqueados y vuelve a cargar los registros de la mquina con los valores iniciales. Sus principales ventajas son:
Cada proceso o hilo puede tener su propio algoritmo o planificacin de proceso.
El intercambio es ms rpido, ya que se utilizan los identificadores en el ncleo.
Tiene una mayor escalabilidad en el incremento de procesos.
En el Ncleo A diferencia de la implementacin en el cliente, la implementacin en el ncleo no necesita el manejo de tiempo de ejecucin; cada proceso dentro del mismo maneja su tabla de procesos, aunque esto signifique un costo mayor en recursos de mquina y tiempo de procesamiento. Una de las ventajas ms relevantes es que no se requiere de llamadas de bloqueo al sistema.
4.2 MODELOS DE SISTEMAS

En un sistema distribuido con varios procesadores un aspecto fundamental en el diseo es como se utiliza a los procesadores que se pueden organizar de varias formas:

De estacin de trabajo De pila de procesadores Hbrido
Pgina 23
De estacin de trabajo Este sistema consta de computadoras dispersas conectadas entre si mediante una red de rea local puede contar o no con disco duro en cada una de ellas, los usuarios tienen una cantidad fija de poder de computo y un alto grado de autonoma para asignar sus recursos locales. La idea consiste en ordenar realmente la ejecucin de procesos en estaciones de trabajo inactivas. 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: Bajo costo, fcil mantenimiento del hardware y del software, simetra y
flexibilidad. Gran uso de la red, los servidores de archivos se pueden convertir en cuellos
de botella. Disco para paginacin y archivos de tipo borrador:
Reduce la carga de la red respecto del caso anterior. Alto costo debido al gran nmero de discos necesarios. Disco para paginacin, archivos de tipo borrador y archivos binarios (ejecutables):
Reduce an ms la carga sobre la red. Alto costo y complejidad adicional para actualizar los binarios. Disco para paginacin, borrador, binarios y ocultamiento de archivos.
Pgina 24
Reduce an ms la carga de red y de
los servidores de archivos. Alto costo. Problemas de consistencia del cach. Sistema local de archivos completo:
Escasa carga en la red. Elimina la necesidad de los servidores
de archivos. Prdida de transparencia.
Modelo de pila de procesadores Este mtodo consiste en construir una pila de procesadores, repleta de CPU, en un cuarto de maquinas, los cuales se pueden asignar de manera dinmica a los usuarios segn la demanda. A cada usuario se le da una terminal grfica de alta rendimiento, como las terminales X, incluso se pueden utilizar terminales ASCII. Ventajas: Precio Elimina la asociacin entre el nmero de usuarios y el de estaciones de trabajo. Facilita el crecimiento por incrementos
De hecho se convierte el poder de cmputo en estaciones de trabajo inactivas, a las que se puede tener acceso de manera dinmica. Aqu no existe el concepto de propiedad. La motivacin para la idea de la pila de procesadores proviene de dar un paso ms adelante en la idea de las estaciones de trabajo sin disco. El principal argumento para la centralizacin del poder de cmputo como pila de procesadores proviene de la teora de colas.
Pgina 25
Aun as, el modelo de pila de procesadores es una forma ms limpia de obtener poder de cmputo adicional estaciones que la bsqueda de
inactivas.
Ningn
procesador pertenece a alguien, no hay mquina origen, no hay peligro de que el poseedor regrese.
Seleccionar pila de procesadores o estaciones de trabajo inactivas va a depender del trabajo que se desarrolle. Modelo de procesador hbrido Se puede establecer una mediacin al proporcionar a cada usuario una estacin de trabajo personal y adems tener una pila de procesadores. Aunque esta solucin es ms cara. Para procesos interactivos sera mejor utilizar estaciones de trabajo, con una respuesta garantizada. Sin embargo las estaciones inactivas no se utilizan, lo cual hace ms sencillo al diseo del sistema. Solo se dejan sin utilizar. En vez de esto todos los interactivos se ejecutan en la pila de procesadores, as como todo el cmputo pesado en general. Este modelo proporciona una respuesta interactiva ms rpida, un uso eficiente de los recursos y un diseo sencillo.
4.3 ASIGNACIN DE PROCESADORES

Por definicin, un sistema distribuido consta de varios procesadores. Estos se pueden organizar como coleccin de estaciones de trabajo personales, una pila pblica de procesadores o alguna forma hbrida. En todos los casos, se necesita cierto algoritmo para decidir cul proceso hay que ejecutar y en qu mquina. Para el modelo de estaciones de trabajo, hay que decidir cundo ejecutar el proceso de manera local y cundo buscar una estacin inactiva. Para el modelo de la pila reprocesadores, hay que tomar una decisin por cada nuevo proceso. Uso de estaciones de trabajo inactivas Plantea el problema de encontrar
estaciones de trabajo inactivas en la red que puedan ejecutar procesos. Por lo cual las estaciones de trabajo deben de anunciar cuando no cuentan con una carga de trabajo asignada, as todas las dems estaciones toman nota de esto y lo registran. 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 pueden dividir en 2 categoras amplias: No migratorias: Al crearse un proceso, se toma una decisin de donde colocarlo. Una vez colocado en la mquina, el proceso permanece ah hasta que termina. No se puede mover, no importa lo sobrecargada que est la mquina. Migratorias: Un proceso se puede trasladar aunque haya iniciado su ejecucin. Permiten un mejor balance de la carga pero son ms complejas y tienen un efecto fundamental en el diseo del sistema. Los algoritmos de asignacin intentan optimizar: Uso de las CPU: Maximizar el nmero 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 proces en cierta mquina dividido por el tiempo que tardara en cierto procesador de referencia.
4.4 PLANIFICACIN
Cada procesador se multiprograma con n espacios para los procesos (multiprogramacin de nivel n). El algoritmo de Ouster hout utiliza el concepto de coplanificacin: Toma en cuenta los patrones de comunicacin entre los procesos durante la planificacin. Debe garantizar que todos los miembros del grupo se ejecuten al mismo tiempo. Se emplea una matriz conceptual donde: = Las filas son espacios de tiempo.= Y las columnas son las tablas de procesos de los procesadores. Cada procesador debe utilizar un algoritmo de planificacin Round Robin. Donde: 1- Todos los procesadores ejecutan el proceso en el espacio 0 durante un cierto perodo fijo. 2- Todos los procesadores ejecutan el proceso en el espacio 1 durante un cierto perodo fijo, etc. 3- Se deben mantener sincronizados los intervalos de tiempo. 4- Todos los miembros de un grupo se deben colocar en el mismo nmero de espacio de tiempo pero en procesadores distintos.
Pgina 28
4.5 TOLERANCIA A FALLAS

Un sistema distribuido es una coleccin de nodos autnomos de computacin que se pueden comunicar unos con otros y que colaboran en un objetivo o tarea comn. Cuando un nodo falla o cuando el subsistema de comunicaciones que permite que los nodos se comuniquen falla, los nodos se han de adaptar a las nuevas condiciones, para que puedan seguir cooperando. En los sistemas tolerantes a fallo. Los fallos que se pueden tolerar son aqullos que est previsto que pueden ocurrir. El primer paso necesario para que un sistema pueda recuperarse de un fallo, es detectarlo. El siguiente paso es llevar al sistema a un estado consistente, para ello, es necesario que las acciones realizadas antes del fallo mantengan la consistencia. La clave para tolerar fallos es la replicacin, es decir, que varios elementos del sistema puedan dar el mismo servicio. A continuacin se definen los modelos de fallo ms frecuentes en la literatura, y las soluciones para conseguir la tolerancia a fallos. Semnticas de fallo Los sistemas de computacin constan de multitud de componentes hardware y software que pueden fallar (debido a un error de diseo, al envejecimiento de los materiales o a un evento externo). En muchos sistemas, estos fallos pueden llegar a producir inconsistencias y, por lo tanto, la no disponibilidad del servicio que estaban ofreciendo. Existen sistemas que se disean para tolerar fallos. Estos sistemas (sistemas tolerantes a fallos) hacen transparente al usuario los modos de fallos previstos en el sistema. A continuacin se hace una taxonoma de los modos de fallo:
Fallo de tipo crash. En este modo, el fallo de un proceso consiste en una parada prematura, es decir, un proceso acta en el sistema correctamente y, en un momento dado, deja de estar operativo.
Derivaciones de este modo de fallo son:
Fallo silencioso. Cuando un proceso falla, deja de interactuar con el resto del sistema.
Pgina 29
Fallo parada. Cuando un proceso falla, avisa de ello a todos los procesos del sistema y luego se para.
Fallo de omisin. Este modo contiene al fallo de tipo crash y, adems, en l se contemplan omisiones en los mensajes que se envan o reciben. Es equivalente a decir que, adems de fallar un proceso, el servicio de comunicacin puede perder mensajes.
Fallo de temporizacin. En los sistemas de tiempo real no slo es importante que los resultados obtenidos sean correctos, sino que adems deben haberse conseguido dentro de unos requisitos temporales. Un fallo de temporizacin, adems de contener el modo de fallo de omisin, aparece cuando un proceso se ejecuta ms rpida o lentamente de lo definido en su especificacin. Si se asocia al servicio de comunicacin, es equivalente a decir que la red transporta los mensajes ms rpidos o ms lentamente de lo que dice su especificacin.
Fallo arbitrario. Tambin conocido como fallo bizantino o malicioso, es un modo de fallo que define un comportamiento no determinista de los procesos. En este modo se engloban todos los modos de fallo anteriores.
Los elementos del sistema pueden no respetar su especificacin en cualquier momento. Cuando se quiere construir un sistema tolerante a fallos, habitualmente se consideran dos alternativas. La primera consiste en ejecutar sistemas software sobre hardware especializado tolerante a fallos (CPU y memoria principal replicadas, discos espejo, varios buses y rutas de datos, entre otros.) pero; debido a razones econmicas, fundamentalmente, la segunda aproximacin est ganando impulso y es la de usar hardware estndar para soportar tolerancia a fallos, replicando ese hardware y manteniendo esa replicacin a nivel software. De esta forma se consigue un sistema distribuido tolerante a fallos. Los protocolos que gestionan las rplicas pueden dividirse en dos clases: los que usan replicacin activa y los que siguen el modelo de primario y respaldo.
Pgina 30
Replicacin activa La replicacin activa (conocida tambin como replicacin mediante mquina de estados) es un mtodo general para construir un sistema tolerante a fallos mediante la replicacin de sus elementos y la coordinacin de las comunicaciones entre ellos. Una mquina de estados est compuesta por un conjunto de variables (estado) y un conjunto de operaciones que modifican o consultan el valor de esas variables. Cada operacin se realiza mediante un programa determinista, y su funcionamiento es atmico respecto al de otras. Las operaciones tambin producir resultados de salida. Cuando un cliente quiere ejecutar un servicio de la mquina de estados, le hace una peticin, indicando qu operacin debe ejecutar. El resultado puede ser la activacin de un actuador o la respuesta a algn cliente que la estaba esperando. Es necesario tambin que las peticiones que recibe una mquina de estados sean atendidas de una en una, en un orden que ha de ser consistente con la causalidad potencial entre ellas. La propiedad fundamental que caracteriza una mquina de estados es que los resultados de salida que produce estn completamente determinados por la secuencia de peticiones que recibe, con independencia del momento en que las recibe y de cualquier otra actividad del sistema. Una gran ventaja de este enfoque consiste en que casi cualquier sistema puede descomponerse en clientes y mquinas de estados, por lo que puede ser utilizado en gran parte de los casos. Para conseguir una versin tolerante a t fallos de una mquina de estados podemos replicarla, colocando cada rplica en un nodo diferente de la red. Si todas las rplicas comienzan en el mismo estado, y reciben la misma secuencia de peticiones, todas harn lo mismo, y producirn los mismos resultados. El nmero de rplicas que son necesarias para tolerar t fallos depende del modelo de fallo que se considere. Si son fallos bizantinos, hacen falta como mnimo 2 t + 1, y para obtener resultados correctos basta con tomar los que producen la mayora de las rplicas. Si se considera que slo puede haber falloparada, basta con t + 1 rplicas. En otras palabras, la clave para conseguir mquinas de estados replicadas tolerantes a fallos est en garantizar la coordinacin entre las rplicas (todas reciben y procesan la misma secuencia de peticiones). Este requisito puede a su vez descomponerse en dos: consenso
(todas las rplicas correctas reciben el mismo conjunto de peticiones) y orden (todas las rplicas correctas procesan las peticiones que reciben en el mismo orden). Los algoritmos de comunicacin que satisfacen el requisito de acuerdo (consenso) deben conseguir que un emisor pueda enviar un mensaje a los receptores cumpliendo dos condiciones: todos los receptores correctos estn de acuerdo en el mensaje que reciben y, si el emisor es correcto, lo que cada receptor correcto recibe es lo que envi el emisor. Los que garantizan estas dos condiciones se llaman protocolos de radiado fiables, protocolos de acuerdo bizantino o, simplemente, protocolos de consenso. El requisito de orden suele satisfacerse aadiendo informacin de orden a los mensajes. Esta informacin puede ser aadida por uno de los receptores (que luego la distribuye a los dems), o por los emisores, mediante el uso de algn tipo de reloj lgico (generalmente, combinado con cierto acuerdo entre los receptores). Consideremos un objeto x, y la invocacin de la operacin [x op (arg) pi] por parte del cliente Pi (Figura 2.5): 1. La peticin se enva a todas las rplicas de x . 2. Cada rplica procesa la peticin, actualiza su estado, y enva la respuesta [x ok (res) pi] al cliente pi. 3. El cliente espera hasta que recibe la primera respuesta, o hasta que recibe todas las respuestas. Si las rplicas no se comportan de manera maliciosa (es decir, no se producen fallos bizantinos),
entonces el proceso cliente espera slo por la primera respuesta. En caso contrario, ser necesario
disponer al menos de 2 f + 1
rplicas para tolerar hasta f posibles fallos. En esta situacin, el cliente espera a recibir slo f + 1 respuestas idnticas. Replicacin mediante primario y respaldos En los sistemas que usan este enfoque para lograr tolerancia a fallos, los emisores envan mensajes slo al proceso marcado como primario. Si ste falla, uno de los respaldos toma su lugar. Los clientes deben darse cuenta de estas cadas y actualizar el primario para poder enviar sus mensajes al proceso adecuado. Ms formalmente, para que un protocolo pueda ser considerado del tipo primario- respaldos, deben cumplir las siguientes condiciones:
Existe un predicado que se puede aplicar al estado de cada servidor. En cualquier
momento, como mucho un servidor satisface ese predicado. El que lo satisface es denominado primario.
Todo cliente mantiene informacin sobre la identidad de un servidor, al que realiza sus peticiones. Este servidor, si es el primario, encola las peticiones y las atiende de una en una.
Si una peticin llega a un servidor que no es el primario, se descarta. El servicio replicado aparece, en su conjunto, como un servidor que, en el peor de los casos, no responde durante un nmero limitado de perodos finitos de tiempo. Las tres primeras propiedades definen cmo debe ser el protocolo entre los clientes y el servicio y la cuarta indica en qu condiciones el servicio debe satisfacer las peticiones.
Consideremos una vez ms la invocacin de la operacin [x op (arg) pi] por parte del cliente pi. En ausencia de fallo del servidor primario, la peticin se maneja de la siguiente forma: 1. El proceso pi enva la peticin x op(arg) a la rplica primaria I1. 2. I1 recibe y ejecuta la peticin. Una vez ejecutada la operacin solicitada I1, enva a las rplicas de respaldo la peticin que se
Pgina 33
recibi del cliente para que stas actualicen su estado. 3. Cuando I1 recibe un reconocimiento desde todos los servidores de reserva, la respuesta es enviada al cliente pi.
4.6 SISTEMAS DE TIEMPO REAL

Los sistemas de tiempo real son aquellos que interactan con el mundo exterior donde el tiempo es un factor importante. Caractersticas. Se activan por evento o por tiempo. Su comportamiento debe ser predecible. Deben ser tolerantes a fallas. La comunicacin en los sistemas distribuidos de tiempo real debe de alto desempeo. Clasificacin. Los sistemas de tiempo real se clasifican en general en dos tipos dependiendo de lo serio de sus tiempos lmite 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 lmite. Un sistema de tiempo real duro es aquel en el que un tiempo lmite no cumplido puede resultar catastrfico. Ejemplo de sistema de tiempo real suave. Conmutador telefnico. Ejemplo de sistema de tiempo real duro. Alarma ssmica. Activacin de sistemas de tiempo 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 algn sensor, lo que entonces provoca que el CPU conectado tenga una interrupcin. Los sistemas activados por eventos estn 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 algn evento externo. La desventaja es que se pierde mucho tiempo de CPU si los eventos ocurren con poca frecuencia.
Pgina 35
CONCLUSION
Los sistemas operativos distribuidos estn teniendo mucho auge en estos tiempos. Son utilizados a menudo como subsistemas operativos aprovechando sus ventajas para un ptimo almacenamiento. Podramos decir que los sistemas operativos distribuidos son en futuro reemplazos de los sistemas operativos normales ya que su fabricacin es con un kernel que puede ser instalado en cualquier maquina sin importar su plataforma. Esperando que este pequeo trabajo haya sido de su agrado. Muchas gracias.
Pgina 36
BIBLIOGRAFIA
www.oocities.org/mx/lyly_sak/sod_unidad3.html blogs.utpl.edu.ec/sistemasoperativos/2009/04/21/interbloqueos-4/ www.iuma.ulpgc.es/users/lhdez/inves/pfcs/memoria-ivan/node2.html m.monografias.com/trabajos6/sidi/sidi.shtml www.rincondelvago.com/ exa.unne.edu.ar/depar/areas/informatica/SistemasOperativos/MonogSO/GESTDP 02_archivos/exclusion.htm exa.unne.edu.ar/depar/areas/informatica/SistemasOperativos/SO9.htm sistemasoperativosequipo5.blogspot.com/2011/07/unidad-3-procesos-yprocesadores-en.html?m=1 m.monografias.com/trabajos55/sincronizacion-sistemasdistribuidos/sincronizacion-sistemas-distribuidos2.shtml exa.unne.edu.ar/depar/areas/informatica/SistemasOperativos/MonogSO/CARSD0 2.htm
Pgina 37

Sos Distribuido

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Sos Distribuido

Caricato da

Copyright:

Formati disponibili

UNIVERSIDAD VALLE DEL GRIJALVA CAMPUS PICHUCALCO

SISTEMAS OPERATIVOS DISTRIBUIDO

T I T U L A R : ING. JESUS GAMALIEL HERNANDEZ CANO

Sistemas operativos distribuidos

Paulino Hernndez Hernndez

Sistemas operativos distribuidos

Paulino Hernndez Hernndez

Sistemas operativos distribuidos

Paulino Hernndez Hernndez

Sistemas operativos distribuidos

A cada cristal se le asocian dos registros:

Cada interrupcin se denomina marca de reloj.

Para una computadora y un reloj:

Importan los tiempos relativos.

Para varias computadoras con sus respectivos relojes:

Si 2 procesos no interactan no es necesario que sus relojes estn sincronizados.

Paulino Hernndez Hernndez

Sistemas operativos distribuidos

Para ciertos algoritmos lo que importa es la consistencia interna de los relojes:

Los relojes fsicos son relojes que:

Se dice que son eventos concurrentes.

Paulino Hernndez Hernndez

Sistemas operativos distribuidos

tiempo de envo, de acuerdo con el reloj del emisor.

Paulino Hernndez Hernndez

Sistemas operativos distribuidos

Paulino Hernndez Hernndez

Sistemas operativos distribuidos

Se dificulta la obtencin del tiempo con una precisin extremadamente alta.

Paulino Hernndez Hernndez

Sistemas operativos distribuidos

Sistemas operativos distribuidos

Sistemas operativos distribuidos

Sistemas operativos distribuidos

Este algoritmo requiere 3* (n-1) mensajes para una solicitud de entrada.

Cuando un proceso quiere entrar en su seccin critica, enva un mensaje de

Paulino Hernndez Hernndez

Sistemas operativos distribuidos

solicitud, a todos los dems procesos. (n-1)

3.3 EXCLUSIN MUTUA

Sistemas operativos distribuidos

Sistemas operativos distribuidos

3.4 TRANSACCIONES ATMICAS

3.5 BLOQUEOS MUTUOS

Sistemas operativos distribuidos

Sistemas operativos distribuidos

3.6 ALGORITMOS DE SINCRONIZACION

Paulino Hernndez Hernndez

Sistemas operativos distribuidos

Sistemas operativos distribuidos

Sistemas operativos distribuidos

Paulino Hernndez Hernndez

Sistemas operativos distribuidos

Sistemas operativos distribuidos

Cada proceso o hilo puede tener su propio algoritmo o planificacin de proceso.

El intercambio es ms rpido, ya que se utilizan los identificadores en el ncleo.

Tiene una mayor escalabilidad en el incremento de procesos.

4.2 MODELOS DE SISTEMAS

De estacin de trabajo De pila de procesadores Hbrido

Paulino Hernndez Hernndez

Sistemas operativos distribuidos

de botella. Disco para paginacin y archivos de tipo borrador:

Paulino Hernndez Hernndez

Sistemas operativos distribuidos