Qué vimos la clase anterior ? RPC y Rendezvous.

1. Qué vimos la clase anterior ?RPC y Rendezvous. RPC y Rendezvous son técnicas de comunicación y sincronización entre procesos que suponen un canal bidireccional.Son ideales para programar aplicaciones Cliente-Servidor. RPC y Rendezvous combinan una interfaz “tipo monitor” con operaciones que se exportan a través de llamadas externas (CALL) con mensajes sincrónicos (demoran al llamador). En RPC existe alguna forma de “sistema operativo” o administrador de procesos que “controla” los procesos servidores. Ante un pedido de un servicio activa (“crea”) el servidor y entrega el servicio al cliente. El Rendezvous supone un modelo de tareas (procesos) concurrentes que pueden jugar el rol de clientes o servidores. Programación Concurrente 2004 - Clase 10

2. Qué vimos la clase anterior ?Ejemplos con RPC y Rendezvous. En RPC discutimos el concepto de procesos y procedimientos en el servidor, con los casos del TIME SERVER, y un FILE SERVER con dos niveles. En ADA vimos el concepto de TASK (como proceso cliente o servidor) y la interacción entre los TASKs a través del rendezvous. En ADA la sincronización tiene la posibilidad de hacer un ACCEPT selectivo (Receive sincrónico) dentro de un SELECT. Por otro lado las colas de pendientes en los ACCEPT de los servidores son manejadas automáticamente por el lenguaje y pueden consultarse para tomar decisiones dinámicamente. Programación Concurrente 2004 - Clase 10

3. Paradigmas para interacción entre procesos. Hemos visto tres esquemas básicos de interacción entre procesos: productor/consumidor, cliente/servidor e interacción entre pares. Los tres esquemas básicos anteriores se pueden combinar de muchas maneras, dando lugar a paradigmas o modelos de interacción entre procesos. Discutiremos 7 paradigmas en esta clase. Paradigma 1: servidores replicados En este caso los servidores manejan (mediante múltiples instancias) recursos compartidos tales como dispositivos o archivos. Programación Concurrente 2004 - Clase 10

4. Paradigmas de interacción entre procesos. Paradigma 2: algoritmos de heartbeat Los procesos preriódicamente deben intercambiar información con mecanismos tipo send/receive. Paradigma 3: algoritmos de pipeline La información recorre una serie de procesos utilizando alguna forma de send/receive. Paradigma 4: probes (send) y echoes(ecos) En este caso la interacción entre los procesos permite recorrer grafos o árboles (o estructuras dinámicas) diseminando información. Programación Concurrente 2004 - Clase 10

5. Paradigmas de interacción entre procesos. Paradigma 5: algoritmos de broadcast Permiten alcanzar una información global en una arquitectura distribuida. Sirven para toma de decisiones distribuidas. Paradigma 6: token passing En muchos casos la arquitectura distribuida recibe una información global a través del viaje de tokens de control o datos. También permite la toma de decisiones distribuídas. Paradigma 7: manager/workers Representa típicamente una implementación distribuida del modelo de bag of tasks. Programación Concurrente 2004 - Clase 10

6. Paradigma de servidores replicados. Programación Concurrente 2004 - Clase 10

7. Paradigma de servidores replicados. Modelos de solución de filósofos. El primer modelo de solución que hemos visto, es el centralizado. En este caso los procesos Filósofo se comunican con un proceso Waiter que decide el acceso o no a los recursos. La segunda solución que llamaremos distribuida supone cinco procesos Waiter cada uno de los cuales maneja un tenedor. Para este problema un Filósofo puede comunicarse con dos Waiters (izquierdo y derecho), solicitando y devolviendo el recurso. Los Waiters NO se comunican entre ellos. En la tercer solución que llamaremos descentralizada, cada Filósofo ve un único Waiter. En cambio los Waiters se comunican entre ellos (de hecho cada uno con sus dos vecinos) para decidir el manejo del recurso asociado a “su” Filósofo. Programación Concurrente 2004 - Clase 10

8. Algoritmos de heartbeat. El paradigma de heartbeat es útil cuando tenemos soluciones iterativas que se quieren paralelizar. Utilizando un esquema “divide & conquer” se distribuye la carga entre workers que realizan cálculos y actualizan con sus resultados a otros workers. Cada “paso” debiera significar un progreso hacia la solución del problema. Esquemáticamente: PROCESS worker [i =1 to numWorkers] { declaraciones e inicializaciones locales; WHILE (no terminado) { send valores a los workers vecinos; receive valores de los workers vecinos; Actualizar valores locales; } } Programación Concurrente 2004 - Clase 10

9. Algoritmos de heartbeat. El ejemplo de image labelling. • Si tenemos una imagen representada en una matriz Image[mxn], en muchos casos es importante separarla en zonas que se identifiquen con un label. • Un modo natural de paralelizar este tipo de aplicaciones es dividir la Imagen en P “strips” o conjunto de filas en las que un proceso trata de poner un label a cada pixel. • Naturalmente en cada ciclo los resultados deben ser trasmitidos entre los procesos vecinos porque las “zonas” pueden ser compartidas. • Las iteraciones pueden ser fijas o tener un proceso coordinador o manager que detecte cuando ninguno de los P procesos workers encontró cambios en el labelling. Programación Concurrente 2004 - Clase 10

10. Algoritmos de heartbeat. Autómatas celulares: el juego de la vida. Muchas aplicaciones de sistemas físicos o biológicos pueden modelizarse como una colección de cuerpos que repetidamente interactúan y evolucionan en el tiempo. Algunos ejemplos muy simples pueden modelizarse con algún tipo de autómata celular. La idea es dividir el espacio en un conjunto de células donde cada una es un autómata finito. Cada transición de estado de una célula se basa en su estado y el de sus células vecinas. Un ejemplo simple es el juego de la vida: en una grilla bidimensional cada nodo es una célula que puede estar viva o muerta. Normalmente cada célula tiene 8 vecinas que influyen en ella. Programación Concurrente 2004 - Clase 10

11. Algoritmos de heartbeat. Autómatas celulares: el juego de la vida. Las reglas de interacción que definimos para las transiciones son: 1- Una célula viva rodeada por 0 o 1 células vivas, MUERE. 2- Una célula viva rodeada por 2 o 3 células vivas, SOBREVIVE. 3- Una célula viva rodeada por 4 o más células vivas, MUERE. 4- Una célula muerta rodeada por exactamente 3 células vivas, REVIVE. Obviamente los procesos (células) interactúan con un paradigma tipo heartbeat, enviando y recibiendo mensajes en cada ciclo. El “juego” dura un número predeterminado de ciclos, por lo que no haría falta coordinador. La inicialización es de toda la grilla, al azar. Programación Concurrente 2004 - Clase 10

12. Algoritmos de heartbeat. Autómatas celulares: el juego de la vida. Sin analizar los bordes y extremos, suponiendo un proceso Cell[i,j] por célula y considerando un send no bloqueante tenemos un código: CHAN exchange[1:n, 1:n] (INT row, column, state); PROCESS cell [i=1 to n, j=1 to n] { INT state; declaraciones de variables; FOR [k =1 to numGenerations] { # intercambiar info con los 8 vecinos FOR [p = i-1 to i+1, q= j-1 to j+1] send exchange [p,q] (i, j, state); FOR [p =1 to 8] { receive exchange [i,j] (row,column, value); guardar el valor de las células vecinas; } Actualizar el estado local; } } Programación Concurrente 2004 - Clase 10

13. Paradigma del Pipelining. Tipos de problemas. Un pipeline es un arreglo lineal de procesos “filtro” que reciben datos de un puerto (canal) de entrada y entregan resultados por un canal de salida. Estos procesos (“workers”) pueden estar en procesadores que operan en paralelo, en un primer esquema a lazo abierto (W1 en el INPUT, Wn en el OUTPUT). Un segundo esquema posible es un pipeline “circular”donde Wn se conecta con W1. Estos esquemas sirven en procesos iterativos o bien donde la aplicación no se resuelve en una pasada por el pipe. En un tercer esquema posible existe un proceso coordinador que maneja la “realimentación” entre Wn y W1. Programación Concurrente 2004 - Clase 10

14. Multiplicación de matrices con un Pipe de procesadores. La multiplicación distribuida de matrices A y B de nxn mediante un pipe no parece una aplicación “natural”. Aquí la resolveremos con un pipe cerrado con coordinador. El coordinador pasará las filas de A por el canal de entrada al Worker 0 y luego las columnas de B al Worker 0 y recibirá en orden inverso las filas del producto C. Cada Worker del pipe tiene tres fases de ejecución: primero recibe las filas de A, guardando la primera que recibe y pasando las restantes. De este modo el Worker Wi tendrá la fila i de A. En la segunda fase realiza n ciclos de recibir una columna de B, pasarla y calcular un producto interior. Luego de los n ciclos, Wi tiene C[i, *]. En la tercer fase todas las filas de C fluyen entre los Workers, terminando en el coordinador. La solución que vemos a continuación es muy interesante por el gran flujo de mensajes (casi continuo) en el pipe y por la importancia del orden en que se envían los datos iniciales y finales. Programación Concurrente 2004 - Clase 10

15. Multiplicación de matrices con un Pipe de procesadores. Coordinador. CHAN vector[n] (DOUBLE v[n]); # mensajes a los Workers CHAN result (DOUBLE v[n]); # filas de C para el coordinador PROCESS Coordinator { DOUBLE A[n,n], B[n,n], C[n,n]; Inicializar A y B; FOR [i=0 to n-1] send vector[0] (A[i, *]); # envía las filas de A FOR [i=0 to n-1] send vector[0] (B[*, i]); # envía las columnas de B FOR [i=n-1 to 0] receive result (C[i, *]); # recibe C en orden inverso } Programación Concurrente 2004 - Clase 10

16. Multiplicación de matrices con un Pipe de procesadores. Workers. PROCESS Worker [w=0 to n-1] { DOUBLE A[n], B[n], C[n]; # fila y columna con las que trabaja DOUBLE temp[n]; # usado para pasar vectores DOUBLE total; # usado para calcular el producto interno # Recibe las filas de A, almacena la primera y pasa las otras receive vector[w] (A); FOR [i= w+1 to n-1] { receive vector[w] (temp); send vector[w +1] (temp); } Programación Concurrente 2004 - Clase 10

17. Multiplicación de matrices con un Pipe de procesadores. Workers. # SEGUNDA FASE # Recibe las columnas de B y calcula el producto interno FOR [j=0 to n-1] { receive vector[w] (B); # Obtiene 1 columna de B IF ( w < n-1) #NO es el último Worker send vector[w+1] (B); # Calcula el producto interno que le corresponde total=0; FOR [k= 0 to n-1] total += A[k] * B[k]; C[j] = total; } Programación Concurrente 2004 - Clase 10

18. Multiplicación de matrices con un Pipe de procesadores. Workers. # TERCERA FASE # Envía su columna de C al siguiente Worker o coordinador IF ( w < n-1) #NO es el último Worker send vector[w+1] (C); ELSE send result(C); # Recibe y pasa filas anteriores de C FOR [j=0 to w-1] { receive vector[w] (temp); # Obtiene 1 fila resultado de C IF ( w < n-1) #NO es el último Worker send vector[w+1] (temp); ELSE send result(temp); } } Programación Concurrente 2004 - Clase 10

19. Paradigma de Prueba-Eco. Clases de problemas. Arboles y grafos son utilizados en muchas aplicaciones distribuidas tales como búsquedas en la WEB, bases de datos, sistemas expertos y juegos. Las arquitecturas distribuidas se pueden asimilar a los nodos de grafos y árboles, con canales de comunicación que los vinculan. El paradigma de prueba-eco se basa en el envío de un mensaje (“probe”) enviado por un nodo a su sucesor y la espera posterior del “eco” que es el mensaje de respuesta. Los algoritmos de prueba-eco son particularmente interesantes cuando se trata de recorrer redes donde no hay (o no se conoce) un número fijo de nodos activos. (ejemplo clásico son las redes móviles). Programación Concurrente 2004 - Clase 10

20. Paradigma de Prueba-Eco. Clases de problemas. Broadcasting. El problema de hacer un broadcast a todos los demás nodos de una red es un clásico en procesamiento distribuido. Un primer enfoque es suponer que algún nodo tiene la topología de la red en alguna forma de matriz donde la entrada [i, j] es true si los nodos están conectados. Resolver el broadcast con un spanning tree supone un nodo que tiene decidido el routing y lo envía a sus sucesores, conjuntamente con el mensaje m. Cada nodo a su vez recibe el mensaje m y el spanning tree t y visualiza cuales son los “hijos” a los que debe reenviar el mensaje. El proceso es asincrónico, pero podría ser sincrónico (menor eficiencia) Programación Concurrente 2004 - Clase 10

21. Paradigma de Prueba-Eco. Broadcasting con spanning tree. TYPE graph = BOOL [n, n]; CHAN probe[n] (graph spanningTree; message m); PROCESS Node [p=0 to n-1] { graph t; message m; receive probe[p] (t,m); FOR [q=0 to n-1 st q es “hijo” de p en t] send probe[q] (t, m); } PROCESS Iniciator { graph topology= topología de la red; graph t = spanning tree de topology; message m = mensaje a enviar por broadcast; send probe[S] (t,m); } Programación Concurrente 2004 - Clase 10

22. Paradigma de Prueba-Eco. Broadcasting SIN spanning tree. # El broadcast se complica cuando NO se conoce la topología. CHAN probe[n] (message m); PROCESS Node [p=1 to n] { BOOL links[n] = vecinos del nodo p; INT num = nro. de vecinos; message m; receive probe[p] (m); # enviar el mensaje a todos los vecinos. FOR [q=0 to n-1 st links[q]] send probe[q] (m); # recibir num -1 copias redundantes de m FOR [q=1 to num-1] receive probe[p] (m); } PROCESS Iniciator { # ejecutado sobre el nodo S message m = mensaje a enviar por broadcast; send probe[S] (m); } Programación Concurrente 2004 - Clase 10

23. Paradigma de Prueba-Eco. Cómo obtener la topología de la red. La solución que construye el spanning tree es obviamente más eficiente, pero requiere conocer la topología de la red (sea un grafo con ciclos o un árbol sin ellos). La idea para obtener la topología de la red puede ser partir de un algoritmo muy similar al anterior (SIN spanning tree) pero pidiendo que en el ECO cada nodo envíe la información que tiene de sus vecinos. De este modo el nodo iniciador en un tiempo puede reconstruir las relaciones entre los nodos y armar el grafo de la topología. Posteriormente puede calcular el spanning tree asociado. Programación Concurrente 2004 - Clase 10

24. Algoritmos de token passing. Otro paradigma de interacción muy utilizado se basa en un tipo especial de mensaje o “token” que puede utilizarse para otorgar un permiso (control) o para recoger información global de la arquitectura distribuida. Un ejemplo típico es el caso de tener que controlar exclusión mútua distribuída (por ejemplo con semáforos distribuidos). Si por ejemplo tenemos una BDD, un monitor activo puede ser la solución más simple; más complejo es implementar semáforos distribuídos en la red (lo cual tiene un alto costo en mensajes tipo broadcast) y una tercer posibilidad que veremos a continuación basada en armar un token ring de procesos que cooperan. Programación Concurrente 2004 - Clase 10

25. Algoritmos de token passing. Si User[1:n] son un conjunto de procesos de aplicación que contienen secciones críticas y no críticas. Hay que desarrollar los protocolos de interacción (E/S a las secciones críticas), asegurando exclusión mútua, no deadlock, evitar demoras innecesarias y eventualmente fairness. Para no ocupar los procesos User en el manejo de los tokens, ideamos un proceso auxiliar (helper) por cada User, de modo de manejar la circulación de los tokens. Cuando helper[i] tiene el token adecuado, significa que User[i] tendrá prioridad para acceder a la sección crítica. Este esquema se ha usado mucho en redes conectadas por un bus, donde todos los nodos tienen el token de acceso al bus cíclicamente. Programación Concurrente 2004 - Clase 10

26. Algoritmos de token passing. CHAN token[1:n] ( ), enter[1:n] ( ), go[1:n] ( ), exit[1:n] ( ); Process Helper[i=1 to n] { WHILE (true) { receive token[i] ( ); # Espera el token IF (not empty (enter[i])) { # User[i] lo necesita ? receive enter[i] ( ) send go [i] ( ); # Otorga el permiso receive exit[i] ( ); # Wait por el exit } send token [ i+1 MOD n] ( ); # Pasa el token al siguiente } } Programación Concurrente 2004 - Clase 10

27. Algoritmos de token passing. Process User[i=1 to n] { WHILE (true) { send enter[i] ( ); # Protocolo de Entrada a la SC receive go[i] ( ); SECCION CRITICA; send exit[i] ( ); # Protocolo de Salida de la SC SECCION NO CRITICA; } } El algoritmo tiende a ser fair si los procesos devuelven el token. En casos reales a veces la circulación de tokens se hace más “lenta” para no demorar los procesos en comunicaciones con los helpers. Programación Concurrente 2004 - Clase 10

28. Manager/Workers con un Bag of Tasks distribuido • El concepto de bag of tasks que vimos supone que un conjunto de workers comparten una “bolsa” que contiene tareas o procesos independientes y datos compartidos. La idea es que los workers pueden hacer uso de los datos y tareas así como crear nuevas instancias o tareas que quedan en la bolsa. Vimos algún ejemplo en LINDA manejando un espacio compartido de tuplas. • La mayor virtud de este enfoque es la escalabilidad y la facilidad para equilibrar la carga de trabajo de los workers. • Ahora analizaremos la implementación de este paradigma con mensajes en lugar de memoria compartida. Para esto un proceso manager implementará la “bolsa” manejando los tasks, comunicándose con los workers y detectando fin de tareas. Programación Concurrente 2004 - Clase 10

29. Ejemplo de Manager/Workers: Multiplicación de matrices ralas. Normalmente el producto de dos matrices A y B de n x n elementos significa el desarrollo de n**2 productos internos de cada fila de A por las columnas de B a fin de obtener C[nxn]. Cada producto interno es la multiplicación elemento a elemento de dos vectores de dimensión n y su suma para obtener un único valor. Sin embargo cuando tenemos matrices “ralas” es decir con gran número de elementos en cero, podemos aprovechar esto para optimizar el producto. (una fila de A en 0 significa una fila de C en 0). INT lengthA[n]; # nro. De elementos no cero en una fila de A pair *elementsA[n]; # puntero al índice y valor de cada no cero de A Programación Concurrente 2004 - Clase 10

30. Manager/Workers: Multiplicación de matrices ralas. Proceso Manager. Module Manager TYPE pair = (INT index, DOUBLE value); op getTask(result INT row, len; result pair [*] elems); op putResult(INT row, len; pair [*] elems); BODY Manager INT lengthA[n], lengthC[n]; pair *elementsA[n], *elementsC[n]; # Se supone A inicializada INT nextRow=0, tasksDone=0; Programación Concurrente 2004 - Clase 10

31. Manager/Workers: Multiplicación de matrices ralas. Proceso Manager. PROCESS Manager { WHILE (nextRow < n OR tasksDone <n) { #Falta mandar tareas o recibir resultados IN getTask(row, len, elems)----> row=nextRow; len = lengthA[i]; copiar los pares de A[i] en elems nextRow++; [ ] putResult (row, len, elems)----> lengthC[row]=len; copiar los pares de elems a *elementsC[row]; taskDone++; } } Programación Concurrente 2004 - Clase 10

32. Manager/Workers: Multiplicación de matrices ralas.Los workers. PROCESS Worker [w = 1 to numWorkers] { INT lengthB[n]; pair *elementsB[n]; # se supone inicializada B INT row, lengthA, lengthC; pair *elementsA, *elementsC; INT r, c, na, nb; DOUBLE sum; WHILE (true) { #Obtener una fila de A y calcular la fila de C CALL getTask(row, lengthA, elementsA); lengthC=0; FOR [ i=0 to n-1] INNER PRODUCT (i); send putResult(row, lengthC, elementsC); } } Programación Concurrente 2004 - Clase 10

33. Transacciones sobre un servidor Una transacción define una secuencia de operaciones realizadas por el servidor, la cual debe ser conceptualmente “atómica” en presencia de múltiples clientes (usuarios) e incluso si el servidor o la estructura de soporte falla. Todos los protocolos de control de concurrencia tratan de demostrar la equivalencia con una secuencia ordenada de operaciones secuenciales. Veremos tres esquemas de control de concurrencia: bloqueos, control optimista y ordenación por tiempo. Programación Concurrente 2004 - Clase 10

34. Operaciones atómicas y Multithreading En un sistema concurrente con múltiples clientes y un servidor, donde los clientes comparten objetos y métodos de acceso a los mismos, es imprescindible asegurar la atomicidad y consistencia de las operaciones sobre los datos  multithreading + sincronización Trabajemos un poco el ejemplo de un servidor bancario y operaciones simples de los clientes  Depositar, Extraer, Consultar Saldo, Consultar últimos Movimientos, Cambiar Clave, Pagar Servicios... Imaginemos el escenario de 3 o 4 tarjetas trabajando sobre la misma cuenta, además de otras operaciones “personales” o “demoradas”. JAVA  Syncronized, Wait, Notify  transparencia para el cliente. Programación Concurrente 2004 - Clase 10

35. Fallas en un sistema C/S. Fallas físicas del servidor= Establecer un proceso de recuperación de fallas que mantenga la integridad de las transacciones y prevenga la propagación de errores. Fallas en los dispositivos de almacenamiento de datos  Memoria RAM, Memoria de disco  Chequeos de paridad, redundancia, discos espejados, avisos de fallas. Fallas en los sistemas de comunicación Retardos arbitrarios, duplicación o modificación de mensajes  Necesidad de verificación, reenvío o cancelación de transacciones. Programación Concurrente 2004 - Clase 10

36. Transacciones Atomicidad. Los clientes necesitan que sus solicitudes al servidor sean “atómicas”, es decir: 1- Estén libres de interferencia de otras operaciones de clientes concurrentes. 2- Se completen exitosamente o bien se retrotraigan sin dejar ningún efecto si el servidor falla. Analicemos el caso de tres clientes sobre el mismo objeto cuenta bancaria, realizando las operaciones de Depositar, Extraer y Consultar. Supongamos un saldo inicial, que el que Deposita lo hace por un monto fijo, el que extrae por un porcentaje y el que Consulta requiere Saldo y ultimas operaciones. Programación Concurrente 2004 - Clase 10

37. Propiedades de Transacciones Atómicas El objetivo de un servidor de transacciones es maximizar la concurrencia (eficiencia)  Se permite la ejecución simultánea, siempre y cuando sean “secuenciables” o “secuencialmente equivalentes”. Esto significa dos aspectos relacionados con la atomicidad: 1- Todo o nada una transacción o finaliza correctamente y los efectos de sus operaciones registrados o NO tiene ningún efecto. 2- Aislamiento Cada transacción debe ser realizada sin interferencia con las demás. Sus resultados intermedios no debieran ser visibles a las demás. Programación Concurrente 2004 - Clase 10

38. Propiedades ACID: Atomicity, Consistency, Isolation, Durability Atomicidad  Una transacción debe ser a todo o nada. Consistencia Los datos y procesos resultantes de una transacción deben mantenerse consistentes por la ejecución de la misma. Aislamiento El tratamiento independiente y protegido de las transacciones evita que los estados intermedios condiciones otras transacciones. Durabilidad Los efectos de una transacción terminada correctamente deben reflejarse en forma estable en el sistema. Programación Concurrente 2004 - Clase 10

39. Acciones relacionadas con Fallas. Si falla un proceso servidor  El proceso será reemplazado por otro que debe abortar todas las transacciones no finalizadas y usar un procedimiento de recuperación de fallas para restaurar el estado de los datos previos a la falla. Si el proceso servidor detecta una falla del cliente  El servidor le da un tiempo de recuperación o de terminación a la/s transacciones del cliente y luego las aborta. Si un proceso cliente detecta una falla del servidor  El cliente debiera informarse de la falla y tener una política para reiniciar las transacciones no concluídas al recuperarse el servidor. En algunos casos se requerirá la interacción humana (depósitos de cheques en los cajeros por ejemplo). Programación Concurrente 2004 - Clase 10

40. Conceptos de Control de Concurrencia Actualizaciones perdidas Tomemos el ejemplo de depósitos concurrentes correspondientes al 20% del saldo, a partir de un saldo dado. Qué pasa si no se secuencializa la operación?? Recuperaciones inconsistentesTomemos el ejemplo de una sucursal que quiere el saldo de las cuentas en ella, mientras se están realizando una transferencia entre dos cuentas. Si bien el dinero no se extrae, la consulta puede dar errónea si no se aisla correctamente la transferencia. Equivalencia secuencial Hay que convertir las operaciones concurrentes en equivalentes secuenciales consistentes. Operaciones conflictivas Hay pares de operaciones que son naturalmente conflictivas y no se pueden realizar simultáneamente sin algún riesgo. Programación Concurrente 2004 - Clase 10

41. Analicemos el problema de Lectores-Escritores BANCO. Discutamos primero el efecto de la prioridad para lectores o escritores en el caso de múltiples clientes de una misma cuenta y considerando sólo Consultar/Depositar Generalicemos el problema a operaciones de Consultar/Depositar/Extraer/Listado de la cuenta, considerando diferentes prioridades. Analicemos ahora la duración temporal de las operaciones y si esta duración depende del cliente (de su ubicación física por ejemplo). Incorporemos el concepto de interacción entre cuentas sobre el mismo servidor (transferencias, débitos automáticos, operaciones en mostrador por ejemplo). Programación Concurrente 2004 - Clase 10

42. Recuperabilidad de transacciones abortadas Lecturas sucias El problema de leer un dato intermedio desde un cliente, de una transacción en curso concurrentemente sobre el mismo objeto. Si esta segunda abortara (imaginemos un depósito), la lectura de la primera sería falsa y podría conducir a un error (imaginemos una extracción o consulta de saldo) Recuperación de la transacción Para evitar el efecto anterior, toda transacción que utilice algún dato intermedio dependiente de una transacción no finalizada debiera ESPERAR antes de darse por finalizada. Abortos en cascada La consecuencia inmediata de lo anterior es que pueden generarse abortos en cascada por “fallas” en transacciones de las que dependan muchas otras. Evitar esto implica MAYOR demora, evitando la lectura de datos de objetos con transacciones no terminadas. Programación Concurrente 2004 - Clase 10

43. Recuperabilidad de transacciones abortadas Escrituras prematuras Si tenemos dos operaciones concurrentes de escritura (supongamos sumar 10% a una cuenta), al abortar una de ellas y tratar de recuperar el estado previo de la cuenta puede llevar a errores. Esto se debe a una “escritura prematura”. Para evitarlo las escrituras deben demorarse hasta completarse todas las demás escrituras pendientes sobre el mismo objeto. Ejecuciones estrictas de las transacciones Mayor seguridad, menor eficiencia. Versiones provisionales Son los valores transitorios de un objeto, mientras la transacción que opera sobre él no está terminada. Deben mantenerse para poder recuperarse de fallos. Programación Concurrente 2004 - Clase 10

44. Bloqueos. Las transacciones deben planificarse de forma que sus efectos sobre los datos compartidos sean secuencialmente equivalentes. Los bloqueos exclusivos permiten asegurar esta equivalencia. Normalmente se habla de dos fases del bloqueo: una de crecimiento de la transacción, en que va bloqueando todo lo que requiere para su ejecución y otra de acortamiento o finalización, en la cual libera todos los objetos bloqueados. Bloquear es imprescindible para poder asegurar la consistencia. El grado de bloqueo definirá la eficiencia de la ejecución concurrente. Programación Concurrente 2004 - Clase 10

45. Bloqueo de dos fases estricto. Las transacciones pueden abortar = se requieren ejecuciones estrictas para evitar las lecturas sucias y las escrituras prematuras. Bajo un régimen de ejecución estricta, una transacción que necesita leer o escribir un objeto debe ser retrasada hasta tanto toda otra transacción que haya escrito el mismo objeto esté terminada o abortada. Para hacer cumplir esta regla, se mantienen todos los bloqueos aplicados durante el progreso de una transacción hasta que ésta se consuma o aborta Bloqueo de dos fases estricto  mayor seguridad y menor eficiencia. ES IMPORTANTE REGULAR LA GRANULARIDAD DE LOS BLOQUEOS. Programación Concurrente 2004 - Clase 10

46. Implementación de Bloqueos. En los servidores, normalmente hay un gestor de bloqueos que mantiene el conjunto de bloqueos (por ejemplo una tabla), donde cada bloqueo es una instancia de la clase BLOQUEO y mantiene al menos la siguiente info: • Identificador del objeto bloqueado. • Identificadores de las transacciones que mantienen el bloqueo. • Tipo de Bloqueo. Notar que el gestor de bloqueo es un “scheduler” de recursos compartidos y como tal debe definirse una política de prioridades y/o asignación de los bloqueos. Programación Concurrente 2004 - Clase 10

47. Bloqueos indefinidos Un bloqueo indefinido es un estado en el que cada miembro de un grupo de transacciones está esperando por algún otro miembro para liberar el bloqueo. Se puede ver en un grafo como un ciclo equivalente a un deadlock. La prevención de un bloqueo indefinido es difícil, porque requeriría convertir en estático todo el pedido de recursos, y realizarlo al inicio de la transacción (tipo semáforo de sección crítica). La detección de un bloqueo indefinido debe llevar a elegir alguna transacción a abortar, para romper el bloqueo. Timeouts Ventajas para romper bloqueos indefinidos. Problemas cuando los sistemas están sobrecargados. Programación Concurrente 2004 - Clase 10

48. Análisis del problema de los múltiples clientes de Banco y los bloqueos Base de datos general de los clientes. Datos distribuidos del cliente en las sucursales del Banco. Acceso concurrente del mismo cliente. Operaciones multicliente, concurrentes en el tiempo y distribuidas geográficamente. Dificultades para hacer bloqueos exclusivos seguros que no resulten en operaciones muy ineficientes. El problema de las comunicaciones. Programación Concurrente 2004 - Clase 10

49. Preguntas y Tareas para la promoción 1- En la solución del autómata celular vista, qué cambiaría si los mensajes fueran sincrónicos? Sería más fácil de resolver en OCCAM o en ADA? 2- Qué crítica le haría al algoritmo de pipelining para multiplicación de matrices? Cómo lo mejoraría? 3- En su concepto, cuál es la mayor virtud del paradigma “bag of tasks”? 4- Si Ud. recuerda el problema de las 8 reinas, cuál paradigma utilizaría para resolverlo en paralelo? Qué defecto le ve a su idea para resolverlo? MATERIAL PARA LEER QUE DEJO EN LA PAGINA WEB: Trabajo sobre el lenguaje SR Trabajo sobre el método de JACOBI Trabajo sobre los dining philosophers. Programación Concurrente 2004 - Clase 10