Memoria Cach En los sistemas de archivos convencionales, el fundamento para la memoria cach es la reduccin de la E/S de disco (lo que

aumenta el rendimiento), en un SAD el objetivo es reducir el trfico en la red. Esquema Bsico, el concepto de memoria cach es sencillo, si los datos necesarios para satisfacer la solicitud de acceso no se encuentran en la memoria cache, se trae una copia de servicio al usuario y los accesos se llevan a cabo con la copia de memoria cach. La idea es conservar all los bloques de disco de acceso mas reciente, para as manejar localmente los accesos repetidos a la misma informacin y no aumentar el trfico de la red. Se utiliza una poltica de reemplazo (por ejemplo, la de utilizacin menos reciente) para limitar el tamao de la memoria cach. Polticas de Actualizacin, la poltica empleada para escribir los bloques de datos modificados en la copia maestra del servidor tiene un efecto decisivo sobre la confiabilidad y el rendimiento del sistema. La poltica mas sencilla consiste en escribir los datos directamente en el disco tan pronto se coloquen en una memoria cach. La ventaja de la escritura directa es su confiabilidad, ya que se pierde poca informacin si un sistema cliente falla. Sin embargo, esta poltica requiere que cada acceso de escritura espere hasta que se enve la informacin al servidor, por lo que representa una escritura de escaso rendimiento. La memoria cach con escritura directa equivale a usar el servicio remoto para accesos de escritura y explotar la memoria cache nicamente para accesos de lectura. NFS proporciona el acceso de escritura directa. Consistencia, una maquina cliente se enfrenta al problema de decidir si una copia de datos en memoria cach local es consistente con la copia maestra ( y por tanto, puede usarse). Si la maquina cliente determina que sus datos en memoria cach estn desfasados, ya no pueden servir para los accesos y hay que colocar en la memoria cach una copia actualizada de los datos. Existen dos enfoques para verificar la validez de los datos en memoria cach ..:
Enfoque iniciado por el cliente, el cliente inicia una comprobacin de validez, en la cual se pone en contacto con el servidor y comprueban si los datos locales son consistentes con la copia maestra. Enfoque iniciado por el servidor, el servidor anota, para cada cliente, las partes de los archivos que coloca en memoria cache, y cuando detecta una inconsistencia, debe reaccionar. Una posible fuente inconsistencia ocurre cuando dos clientes, que trabajan en modos conflictivos, colocan en memoria cach un archivo.

Comunicacin en grupos (Algoritmos Para la Sincronizacin de Relojes) Si una mquina tiene un receptor de UTC, todas las mquinas deben sincronizarse con ella. Si ninguna mquina tiene un receptor de UTC: Cada mquina lleva el registro de su propio tiempo. Se debe mantener el tiempo de todas las mquinas tan cercano como sea posible. Se supone que cada mquina tiene un cronmetro que provoca una interrupcin h veces por segundo. Cuando el cronmetro se detiene, el manejador de interrupciones aade 1 a un reloj en software. El reloj en software mantiene un registro del nmero de

marcas (interrupciones) a partir de cierta fecha acordada antes; al valor de este reloj se lo llama C. Algoritmo de Cristian Es adecuado para sistemas en los que: Una mquina tiene un receptor UTC, por lo que se la llama despachador del tiempo. El objetivo es sincronizar todas las mquinas con ella. Cada mquina enva un mensaje al servidor para solicitar el tiempo actual, peridicamente, en un tiempo no mayor que / 2 segundos. El despachador del tiempo responde prontamente con un mensaje que contiene el tiempo actual CUTC. Cuando el emisor obtiene la respuesta puede hacer que su tiempo sea CUTC. Un gran problema es que el tiempo no puede correr hacia atrs: CUTC no puede ser menor que el tiempo actual C del emisor. La atencin del requerimiento en el servidor de tiempos requiere un tiempo del manejador de interrupciones. Tambin se debe considerar el tiempo de transmisin. El cambio del reloj se debe introducir de manera global: Si el cronmetro genera 100 interrupciones por segundo:
Cada interrupcin aade 10 mseg al tiempo. Para atrasar solo agregara 9 mseg. Para adelantar agregara 11 mseg.

La correccin por el tiempo del servidor y el tiempo de transmisin se hace midiendo en el emisor: El tiempo inicial (envo) T0. El tiempo final (recepcin) T1. Ambos tiempos se miden con el mismo reloj. El tiempo de propagacin del mensaje ser (T1 - T0) / 2. Si el tiempo del servidor para manejar la interrupcin y procesar el mensaje es I: El tiempo de propagacin ser (T1 - T0 - I) / 2. Para mejorar la precisin: Se toman varias mediciones. Se descartan los valores extremos. Se promedia el resto. El tiempo de propagacin se suma al tiempo del servidor para sincronizar al emisor cuando ste recibe la respuesta. Algoritmo de Berkeley En el algoritmo de Cristian el servidor de tiempo es pasivo. En el algoritmo de Berkeley el servidor de tiempo: Es activo. Realiza un muestreo peridico de todas las mquinas para preguntarles el tiempo. Con las respuestas:
Calcula un tiempo promedio. Indica a las dems mquinas que avancen su reloj o disminuyan la velocidad del mismo hasta lograr la disminucin requerida.

Es adecuado cuando no se dispone de un receptor UTC. Algoritmos con Promedio Los anteriores son algoritmos centralizados. Una clase de algoritmos descentralizados divide el tiempo en intervalos de resincronizacin de longitud fija: El i -simo intervalo:
Inicia en T0 + i R y va hasta T0 + (i + 1) R.

T0 es un momento ya acordado en el pasado. R es un parmetro del sistema.

Al inicio de cada intervalo cada mquina transmite el tiempo actual segn su reloj. Debido a la diferente velocidad de los relojes las transmisiones no sern simultneas. Luego de que una mquina transmite su hora, inicializa un cronmetro local para reunir las dems transmisiones que lleguen en cierto intervalo S. Cuando recibe todas las transmisiones se ejecuta un algoritmo para calcular una nueva hora para los relojes. Una variante es promediar los valores de todas las dems mquinas. Otra variante es descartar los valores extremos antes de promediar (los m mayores y los m menores). Una mejora al algoritmo considera la correccin por tiempos de propagacin. Varias Fuentes Externas de Tiempo Los sistemas que requieren una sincronizacin muy precisa con UTC se pueden equipar con varios receptores de UTC. Las distintas fuentes de tiempo generaran distintos rangos (intervalos de tiempo) donde caern los respectivos UTC, por lo que es necesaria una sincronizacin. Como la transmisin no es instantnea se genera una cierta incertidumbre en el tiempo. Cuando un procesador obtiene todos los rangos de UTC: Verifica si alguno de ellos es ajeno a los dems y de serlo lo descarta por ser un valor extremo. Calcula la interseccin (en el tiempo) de los dems rangos. La interseccin determina un intervalo cuyo punto medio ser el UTC y la hora del reloj interno. Se deben compensar los retrasos de transmisin y las diferencias de velocidades de los relojes. Se debe asegurar que el tiempo no corra hacia atrs. Se debe resincronizar peridicamente desde las fuentes externas de UTC. Exclusin Mutua Cuando un proceso debe leer o actualizar ciertas estructuras de datos compartidas: Primero ingresa a una regin crtica para lograr la exclusin mutua y garantizar que ningn otro proceso utilizar las estructuras de datos al mismo tiempo. En sistemas monoprocesadores las regiones crticas se protegen con semforos, monitores y similares. En sistemas distribuidos la cuestin es ms compleja. Un Algoritmo Centralizado La forma ms directa de lograr la exclusin mutua en un sistema distribuido es simular a la forma en que se lleva a cabo en un sistema monoprocesador. Se elige un proceso coordinador. Cuando un proceso desea ingresar a una regin crtica: Enva un mensaje de solicitud al coordinador:
Indicando la regin crtica. Solicitando permiso de acceso.

Si ningn otro proceso est en ese momento en esa regin crtica:

El coordinador enva una respuesta otorgando el permiso.

 Cuando llega la respuesta el proceso solicitante entra a la regin crtica. Si un proceso pide permiso para entrar a una regin crtica ya asignada a otro proceso: El coordinador no otorga el permiso y encola el pedido. Cuando un proceso sale de la regin crtica enva un mensaje al coordinador para liberar su acceso exclusivo: El coordinador extrae el primer elemento de la cola de solicitudes diferidas y enva a ese proceso un mensaje otorgando el permiso, con lo cual el proceso queda habilitado para acceder a la regin crtica solicitada. Es un esquema sencillo, justo y con pocos mensajes de control. La limitante es que el coordinador puede ser un cuello de botella y puede fallar y bloquear a los procesos que esperan una respuesta de habilitacin de acceso. Un Algoritmo Distribuido El objetivo es no tener un nico punto de fallo (el coordinador central). Un ej. es el algoritmo de Lamport mejorado por Ricart y Agrawala. Se requiere un orden total de todos los eventos en el sistema para saber cul ocurri primero. Cuando un proceso desea entrar a una regin crtica: Construye un mensaje con el nombre de la regin crtica, su nmero de proceso y la hora actual. Enva el mensaje a todos los dems procesos y de manera conceptual a l mismo. Se supone que cada mensaje tiene un reconocimiento. Si el receptor no est en la regin crtica y no desea entrar a ella, enva de regreso un mensaje o.k. al emisor. Si el receptor ya est en la regin crtica no responde y encola la solicitud. Si el receptor desea entrar a la regin crtica pero an no lo logr, compara: La marca de tiempo del mensaje recibido con, La marca contenida en el mensaje que envi a cada uno. La menor de las marcas gana. Si el mensaje recibido es menor el receptor enva un o.k. Si su propio mensaje tiene una marca menor el receptor no enva nada y encola el pedido. Luego de enviar las solicitudes un proceso: Espera hasta que alguien ms obtiene el permiso. Cuando llegan todos los permisos puede entrar a la regin crtica. Cuando un proceso sale de la regin crtica: Enva mensajes o.k. a todos los procesos en su cola. Elimina a todos los elementos de la cola. La exclusin mutua queda garantizada sin bloqueo ni inanicin. El nmero de mensajes necesarios por entrada es 2(n - 1), siendo n el nmero total de procesos en el sistema. No existe un nico punto de fallo sino n: Si cualquier proceso falla no responder a las solicitudes. La falta de respuesta se interpretar como negacin de acceso: o Se bloquearn los siguientes intentos de los dems procesos por entrar a todas las regiones crticas. Se incrementa la probabilidad de fallo en n veces y tambin el trfico en la red. Se puede solucionar el bloqueo si: El emisor espera y sigue intentando hasta que regresa una respuesta o, El emisor concluye que el destinatario est fuera de servicio. Otro problema es que: Se utilizar una primitiva de comunicacin en grupo o, Cada proceso debe mantener la lista de miembros del grupo, incluyendo los procesos que ingresan, los que salen y los que fallan. Se complica para gran nmero de procesos. Un importante problema adicional es que: Todos los procesos participan en todas las decisiones referentes a las entradas en las regiones crticas. Se sobrecarga el sistema. Una mejora consiste en permitir que un proceso entre a una regin crtica con el permiso de una mayora simple de los dems procesos (en vez de todos): Luego de que un proceso otorg el permiso a otro para entrar a una regin crtica, no puede otorgar el mismo permiso a otro proceso hasta que el primero libere su permiso. Algoritmos de Eleccin

Son los algoritmos para la eleccin de un proceso coordinador, iniciador, secuenciador, etc.. El objetivo de un algoritmo de eleccin es garantizar que iniciada una eleccin sta concluya con el acuerdo de todos los procesos con respecto a la identidad del nuevo coordinador. Transacciones Atmicas Las tcnicas de sincronizacin ya vistas son de bajo nivel:
El La El La La programador debe enfrentarse directamente con los detalles de: exclusin mutua. manejo de las regiones crticas. prevencin de bloqueos. recuperacin de fallas.

Se precisan tcnicas de abstraccin de mayor nivel que:

Oculten estos aspectos tcnicos. Permitan a los programadores concentrarse en los algoritmos y la forma en que los procesos trabajan juntos en paralelo.

Tal abstraccin la llamaremos transaccin atmica, transaccin o accin atmica. La principal propiedad de la transaccin atmica es el todo o nada:
O se hace todo lo que se tena que hacer como una unidad o no se hace nada. Ejemplo: Un cliente llama al Banco mediante una PC con un mdem para: Retirar dinero de una cuenta. Depositar el dinero en otra cuenta. La operacin tiene dos etapas. Si la conexin telefnica falla luego de la primer etapa pero antes de la segunda: Habr un retiro pero no un depsito. La solucin consiste en agrupar las dos operaciones en una transaccin atmica: Las dos operaciones terminaran o no terminara ninguna. Se debe regresar al estado inicial si la transaccin no puede concluir.

El Modelo de Transaccin Supondremos que: El sistema consta de varios procesos independientes que pueden fallar aleatoriamente. El software subyacente maneja transparentemente los errores de comunicacin.