Control de concurrencia Un algoritmo para control de concurrencia en SS.DD se basa en el uso de la cerradura P.ej. al acceder a un archivo, se activa una cerradura de acceso La cerradura puede ser de lectura/escritura La cerradura puede ser a todo el fichero o a ciertos registros (granularidad de la cerradura) La cerradura más usada es la de dos fases: primero se va intentando adquirir todas las cerraduras necesarias, y solo entonces se accede Si no se pudiera acceder a una de las cerraduras, se liberan las ya obtenidas
Control de concurrencia Otra opción es el control optimista de la concurrencia La idea es no hacer nada Se supone que van a producirse pocos conflictos, en la práctica los conflictos son raros, por lo que suele funcionar bien Pero hay que detectar los conflictos. Si se producen hay que deshacer lo hecho
Control de concurrencia Otro método se basa en las marcas de tiempo Se asocia a cada inicio de transacción (BEGIN_TRANSACTION) una marca de tiempo Cuando las transacciones son breves y espaciadas en el tiempo entonces no habrá problema A veces el orden es incorrecto (se detecta que una transición iniciada posteriormente a la transacción activa ha intentado entrar en el archivo, tenido acceso a éste y ha realizado un compromiso) En ese caso la transición activa se aborta
Bloqueos en SS.DD Los bloqueos en los ss.dd. son similares a los que ocurren en un sistema uniprocesador Pero son más difíciles de detectar y corregir Aproximaciones posibles: El algoritmo del avestruz (ignorar el problema) Detección (permitir que ocurran bloqueos, detectarlos e intentar recuperarse) Prevención (imponer restricciones para que podamos asegurar que no se van a dar bloqueos) Evitarlos (que los procesos hagan una cuidadosa asignación de recursos para que no se den bloqueos) Estudiaremos a continuación solo la detección y la prevención
Bloqueos en SS.DD detección centralizada de bloqueos: cada máquina mantiene su gráfica de recursos y procesos Un coordinador recibe (mediante mensajes) esa información. Con la visión global, toma las decisiones Cuando el coordinado detecta un ciclo, elimina los procesos para romper el bloqueo
Bloqueos en SS.DD detección distribuida de bloqueos (algoritmo de Chandy-Misra-Haas): Cuando un proceso debe esperar por un recurso, construye un mensaje especial de exploración, que envía al proceso o procesos que retienen el recurso El mensaje consta de tres números: el proceso que espera, el proceso que envía el mensaje y el proceso al cual se envía Al llegar el mensaje, el receptor comprueba si él también espera a algunos procesos. En ese caso el mensaje se actualiza, conservando el primer campo pero pero reemplazando el segundo por su propio número de proceso y el tercero por el nº del proceso al cual espera El mensaje se reenvía entonces al proceso por el cual espera Si un mensaje regresa al emisor original (el proceso enumerado en el primer campo) es que hay un ciclo y el sistema está bloqueado
Bloqueos en SS.DD 0 1 2 0 1 2 1 2 0 (0,2,3) (0,4,6) (0,5,7) (0,8,0) Máquina 0 Máquina 1 Máquina 2 Ejemplo:
Bloqueos en SS.DD Prevención distribuida de bloqueos: Suponemos que existe un s.d. con tiempo global y transacciones atómicas Asociamos a cada transacción una marca de tiempo global al momento de su inicio Cuando un proceso está a punto de bloquearse en espera de un recurso que está usando otro proceso, se comprueba cuál de ellos tiene la marca de tiempo mayor Si el proceso que tiene el quiere el recurso es más joven podemos entonces optar por hacerlo esperar
Tolerancia a fallos Un sistema falla cuando no cumple su especificación Los fallos de un sistema pueden estar en un fallo en algún componente. Los fallos de componentes pueden ser: fallos transitorios: una erupción solar que inutiliza un momento un satélite?? fallos intermitentes: mal contacto en un cable,… fallos permanentes: circuito quemado, error software,…
Tolerancia a fallos Los fallos del sistema pueden ser: fallos silenciosos: el sistema deja de funcionar o se puede detectar que el sistema ha dejado de funcionar correctamente fallos bizantinos: no se detecta, el sistema sigue funcionando pero produce resultados incorrectos Desde el punto de vista de la t.a.f, los sistemas pueden ser: síncronos: si se puede asegurar que el sistema responde a un mensaje dentro de un tiempo finito conocido asíncronos: si no Los sistemas más problemáticos son pues los que tienen fallos bizantinos y los que son asíncronos
| Página siguiente |