Mecanismos de comunicación y sincronización entre procesos.

Mecanismos de comunicación y sincronización entre procesos.
Memoria compartida: Los procesos intercambian mensajes sobre la memoria compartida o actúan coordinadamente sobre datos residentes en ella. Lógicamente los procesos no pueden operar simultáneamente sobre la memoria compartida, lo que obligará a BLOQUEAR y LIBERAR el acceso a la memoria. La solución más elemental será una variable de control tipo “semáforo” que habilite o no el acceso de un proceso a la memoria compartida. Pasaje de Mensajes: Es necesario establecer un “canal” (lógico o físico) para trasmitir información entre procesos. También el lenguaje debe proveer un protocolo adecuado. Para que la comunicación sea efectiva los procesos deben “saber” cuando tienen mensajes para leer y cuando deben trasmitir mensajes. Sistemas Distribuidos Clase 1

Mecanismos de comunicación y sincronización entre procesos.
Independientemente del mecanismo de comunicación / sincronización entre los procesos, los lenguajes de programación concurrente deberán proveer primitivas adecuadas para la especificación e implementación de las mismas. De un lenguaje de programación concurrente se requiere: Indicar las tareas o procesos que pueden ejecutarse concurrentemente. Mecanismos de exclusión mútua. Mecanismos de comunicación entre los procesos. Recordar el ejemplo de ADA. Sistemas Distribuidos Clase 1

Programación Distribuida
Los métodos de sincronización que han visto se basan en leer y escribir variables compartidas, lo cual significa que los programas concurrentes se ejecuten sobre hardware con acceso a memoria compartida. Las arquitecturas de memoria distribuida son cada vez más habituales. Esto implica procesadores + memoria local + red de comunicaciones + otro mecanismo de comunicación/sincronización----> mensajes. Para escribir programas sobre una arquitectura de memoria distribuida, es necesario definir la interfaz con el sistema de comunicaciones---> primitivas de pasaje de mensajes ---> los procesos no comparten memoria, sino canales (físicos o lógicos). Sistemas Distribuidos Clase 1

Programación Distribuida
Los programas concurrentes que se comunican por mensajes se denominan programas distribuidos. Esto supone la ejecución sobre una arquitectura de memoria distribuída, aunque puedan ejecutarse sobre una arquitectura de memoria compartida ( o híbrida). En un programa distribuido los canales son el único objeto que los procesos comparten ===> no hay acceso concurrente a variables y la exclusión mutua no requiere ningún mecanismo especial. Entre los mecanismos para la programación distribuida (que dependen del modo en que interactúan los procesos) tenemos productores-consumidores, clientes-servidores e interacción entre pares. Sistemas Distribuidos Clase 1

Programación Distribuida. Conceptos de pasaje de mensajes.
Los canales pueden proveer comunicaciones half-duplex o full-duplex. A su vez estas comunicaciones pueden ser asincrónicas (no bloqueantes) o sincrónicas (bloqueantes). Las combinaciones dan lugar a AMP, SMP, RPC y Rendezvous que son los 4 mecanismos (equivalentes funcionalmente ya que pueden intercambiarse) cuya sintaxis y semántica serán nuestro objetivo. Si bien decimos que son equivalentes, veremos que AMP y SMP son mejores para modelos tipo productor-consumidor o pares interactivos, mientras RPC y Rendezvous serán más útiles para esquemas C-S. El pasaje de mensajes (AMP o SMP) puede verse como una extensión de semáforos con datos. En RPC y Rendezvous se combina la interfaz procedural de los monitores con pasaje de mensajes implícito. Sistemas Distribuidos Clase 1

Pasaje de mensajes asincrónicos.
En ASM los canales son colas de mensajes que han sido enviados y aún no recibidos: chan ch(id1 : tipo1, ... , idn : tipon ) chan input(char); chan disk_access(INT cylinder, INT block, INT count, CHAR* buffer); chan result[n] (INT); {arreglo de canales} Un proceso agrega un mensaje al final de la cola de un canal ejecutando un send, que no bloquea al emisor send ch(expr1, ... , exprn); Un proceso recibe un mensaje desde un canal con un receive, que demora al receptor hasta que en el canal haya al menos un mensaje; luego toma el primer mensaje y lo almacena en variables locales receive ch(var1, ... , varn); Sistemas Distribuidos Clase 1

Pasaje de mensajes asincrónicos.
Las variables del receive deben tener los mismos tipos que la declaración del canal ch. Receive es una primitiva bloqueante, ya que produce un delay. Sin embargo la semántica es que el proceso NO hace nada hasta recibir un mensaje en la cola correspondiente al canal ch; NO es necesario hacer polling (aquí tendríamos busy waiting) El acceso a los contenidos de cada canal es atómico y se respeta el orden FIFO. En principio los canales son ilimitados, aunque las implementaciones reales tendrán un tamaño de buffer asignado. Se supone que los mensajes NO se pierden ni modifican y que todo mensaje enviado en algún momento puede ser “leído”. empty(ch)determina si la cola de un canal está vacía Sistemas Distribuidos Clase 1

Pasaje de mensajes asincrónicos. Un primer ejemplo.
Veremos un proceso filtro que recibe caracteres desde el canal entrada y los ensambla en líneas que envía al canal salida. CR indica el final de una línea de entrada; una línea contiene a lo sumo CANTMAX caracteres; el caráter especial EOL se agrega a la salida como fin de línea. chan entrada(char), salida(char [CantMax]); Process Carac_a_Linea { char linea [CantMax], int i := 0; WHILE true { receive entrada (linea[i]); WHILE linea[i]  CR and i < CantMax { i := i + 1; receive entrada (linea[i]); } linea [i] := EOL; send salida(linea); i := 0 } } Sistemas Distribuidos Clase 1

Pasaje de mensajes asincrónicos. Un primer ejemplo.
En el ejemplo anterior los canales Entrada y Salida son declarados globales a los procesos, ya que pueden ser compartidos. Cualquier proceso puede enviar o recibir por alguno de los canales declarados, que a veces se denominan mailboxes. En algunos casos un canal tiene un solo receptor y muchos emisores. Entonces se lo llama input port. Si sucede la inversa (muchos receptores, un solo emisor) se lo denomina link ya que provee un “camino” entre el emisor y sus receptores. Empty (ch) puede servir cuando un proceso NO quiere demorarse haciendo receive de un canal sin datos (imaginar un scheduler con varios canales que servir). Sistemas Distribuidos Clase 1

Programación Distribuida: Filtros---> Red de ordenación de datos
Un filtro es un proceso que recibe mensajes de uno o más canales de entrada y envía mensajes a uno o más canales de salida. La salida de un filtro es función de su estado inicial y de los valores recibidos. Esta función del filtro puede especificarse por un predicado adecuado que relacione los valores de los mensajes de salida con los de entrada. Si consideramos el problema de ordenar una lista de N números de modo ascendente podemos pensar en un filtro SORT que tiene un canal de entrada (N números desordenados) y un canal de salida (N números ordenados). Process SORT { receive todos los números del canal INPUT; ordenar los números; send de los números ordenados por el canal OUTPUT; } Sistemas Distribuidos Clase 1

El primer problema es que debemos conocer N. Para esto podemos enviar N como el primer elemento a recibir por el canal INPUT, o bien cerrar la lista de N números con un valor especial o “centinela”. Podemos encarar una solución más eficiente que la “secuencial” pensando en una red de procesos que ejecutan en paralelo e interactúan para “armar” la salida ordenada. (merge network). La idea es mezclar repetidamente y en paralelo dos listas ordenadas de N1 elementos cada una en una lista ordenada de 2*N1 elementos. En nuestro esquema de AMP estamos pensando en 2 canales de entrada por cada canal de salida. Un carácter especial EOS cerrará cada lista parcial ordenada. Sistemas Distribuidos Clase 1

La red es construida con filtros Merge Cada Merge recibe valores de dos streams de entrada ordenados, in1 e in2, y produce un stream de salida ordenado, out Cómo implemento Merge ? a) Recibir todos los valores, mezclarlos, y enviar la lista mezclada a out (requiere almacenar todos los valores de entrada) b) Comparar repetidamente los próximos dos valores recibidos desde in1 e in2 y enviar el menor a out Sistemas Distribuidos Clase 1

Filtros---> Proceso MERGE
char in1(int), in2(int), out(int); Process Merge { INT v1, v2; receive in1(v1); receive in2(v2); WHILE v1  EOS and v2  EOS { IF v1  v2  send out(v1); receive in1(v1); } ELSE send out(v2); receive in2(v2); } # (v2 < v1) } #Consumir el resto de los datos  IF (v1 == EOS) WHILE ( v2  EOS) { send out(v2); receive in2(v2);} ELSE # (v2 == EOS)  WHILE ( v1  EOS) { send out(v1); receive in1(v1);} #Agregar el centinela al final send out (EOS) ; Sistemas Distribuidos Clase 1

Filtros---> Proceso MERGE
Sistemas Distribuidos Clase 1

Clientes y Servidores. Un Servidor es un proceso que maneja pedidos (“requests”) de otros procesos clientes. Veremos como implementar C-S con AMP. Ahora analizaremos como convertir monitores en servidores y como manejar recursos compartidos. Los ejemplos muestran la dualidad entre monitores y pasaje de mensajes: cada uno de ellos puede simular al otro. monitor Mname { declaración de variables permanentes; código de inicialización; procedure op(formales) { cuerpo de op; } Sistemas Distribuidos Clase 1

Monitores Activos. C-S con 1 operación
Para simular Mname, usamos un proceso server Sname. Las variables permanentes serán variables locales de Sname. Un proceso cliente que envía un mensaje a un canal de request; luego recibe el resultado desde un canal de reply propio. chan request (INT IdCliente, tipos de los valores de entrada ); chan reply[n] (tipos de los resultados ); Process Server { INT IdCliente; declaración de variables permanentes; código de inicialización; WHILE true { receive request (IdCliente, valores de entrada); cuerpo de la operación op; send reply[IdCliente](resultados); } Process Client [i=0 to n-1] { send request(i, argumentos) # “llama” a op receive reply[i] (resultados) # espera el reply Sistemas Distribuidos Clase 1

Clientes-Servidor con múltiples operaciones.
Generalizando esta solución de C-S con una sóla operación, podemos considerar el caso de múltiples operaciones. El IF en el servidor funciona como un CASE que bifurca a diferentes clases de operaciones. El cuerpo de cada operación toma los datos de un canal de entrada en args y los devuelve al cliente adecuado en results. type op_kind = enum(op1, ..., opn); type arg_type = union(arg1 : atype1, ..., argn : atypen ); type result_type = union(res1 : rtype1, ..., resn : rtypen ); chan request(INT IdCliente, op_kind, arg_type); chan reply[n](res_type); Process Server Process Client [i=0 to n-1] Sistemas Distribuidos Clase 1

Process Server { INT IdCliente; OP_KIND kind; ARG_TYPES args; RES_TYPE results; #otras declaraciones de variables código de inicialización; WHILE ( true) { receive request(IdCliente, kind, args); IF ( kind == op1 ) { cuerpo de op1;}  ... ELSE IF ( kind == opn ) { cuerpo de opn;} } send reply[IdCliente](results); Sistemas Distribuidos Clase 1

Process Client [i = 0 to n-1] { ARG_TYPE myargs; RESULT_TYPE myresults; # poner los valores de los argumentos en myargs; send request(i, opk, myargs); # “llama” a opk receive reply[i] (myresults); # espera el reply } Sistemas Distribuidos Clase 1

Dualidad entre monitores y Pasaje de Mensajes para manejar recursos.
Veremos un problema más general: hasta ahora nuestro Monitor no requería variables de condición---> Server no requería demorar la atención de un pedido de servicio. Ahora veremos el caso general de un monitor que tiene múltiples operaciones y utiliza sincronización por condición. Para los clientes, esta situación es transparente ---> cambia el servidor. Consideraremos un caso específico de manejo de múltiples unidades de un dado recurso (bloques de memoria , PRNs por ejemplo). Los clientes “adquieren” y devuelven unidades del recurso. Las unidades libres se insertan en un “conjunto” sobre el que se harán las operaciones de INSERTAR y REMOVER. Obviamente el número de unidades disponibles será lo que controlará nuestra variable de sincronización por condición. Sistemas Distribuidos Clase 1

monitor Resource_Allocator { INT avail = MAXUNITS; SET units = valores iniciales; COND free; # TRUE cuando hay recursos procedure acquire( INT Id ) { IF (avail == 0) wait(free); ELSE avail := avail - 1; remove(units, id); } procedure release( INT id ) { insert(units, id); IF (empty(free)) avail := avail + 1; signal(free); Sistemas Distribuidos Clase 1

type op_kind = enum(ACQUIRE,RELEASE); chan request(INT IdCliente, OP_KIND kind , INT unitid ); chan reply[n] (INT unitid); Process Allocator { INT avail= MAXUNITS; SET units = valor inicial disponible; QUEUE pending; # Inicialmente vacía # declaración de otras variables; sigue Sistemas Distribuidos Clase 1

WHILE (true) { receive request(IdCliente, kind, unitid); IF (kind == ACQUIRE) { IF (avail > 0) { # puede atender el pedido ahora avail := avail - 1; remove(units, unitid); send reply[IdCliente](unitid); } ELSE # recordar el pedido insert(pending, IdCliente); ELSE # significa que el pedido es un RELEASE IF empty(pending) avail := avail + 1; insert(units,unitid); ELSE { # darle unitid a un cliente esperando remove(pending, IdCliente); Sistemas Distribuidos Clase 1

Process Client[i=0 to n-1] { INT unitid; send request(i, ACQUIRE, 0) # “llama” a request receive reply[i](unitid); # usa el recurso unitid, y luego lo libera; send release(i, RELEASE, unitid); } Sistemas Distribuidos Clase 1

La eficiencia de monitores o pasaje de mensajes depende de la arquitectura física de soporte. Con memoria compartida conviene la invocación a procedimientos y la operación sobre variables de condición. Con arquitecturas físicamente distribuida tienden a ser más eficientes los mecanismos de pasaje de mensajes. En general los sistemas operativos y los lenguajes de programación tienden a facilitar la utilización de ambos mecanismos. Sistemas Distribuidos Clase 1

File Servers: Un ejemplo de Cliente-Servidor con AMP
Los procesos “cliente” pueden acceder a archivos externos, almacenados en disco. Deben hacer un OPEN del archivo; si el archivo se puede abrir pueden hacer una serie de pedidos de READ o WRITE y luego pueden cerrar (CLOSE) el archivo. Si tenemos N archivos, consideraremos 1 File Server por archivo.Los procesos server serán idénticos, y cualquiera de ellos que esté libre podrá atender un requerimiento de OPEN. Todos los clientes podrán pedir un OPEN por un canal global (qué argumentos serán necesarios??) y recibirán respuesta de un servidor dado por un canal propio. Por qué?? Sistemas Distribuidos Clase 1

File Servers: Un ejemplo de Cliente-Servidor con AMP .
type kind = enum(READ,WRITE,CLOSE) chan open (STRING fname; INT clientid); chan access[n] (INT kind, otros tipos de argumentos); chan open_reply[m](INT serverId); #Nro. Server o Cod. Error chan access_reply[m] (tipos resultado); #datos, flags de error Client [j=0 to m-1] { INT serverId; otras declaraciones; send open (“Pirulo.doc”, j); # trata de abrir el archivo receive open_reply[j] (serverId); # Nro. de servidor send access[serverid](argumentos de pedido); receive access_reply[j](resultados); ..... } Sistemas Distribuidos Clase 1

Process File_Server[i=0 to n-1] { STRING fname; INT clientId; Kind k; otras declaraciones; BOOL more= false; WHILE (true) { receive open(fname,clientid); OPEN FILE fname ; IF OK THEN { send open_reply[clientid](i); more := true; WHILE more { receive access[i](k,args); IF k == READ procesa pedido de lectura; ELSE IF k == WRITE procesa pedido de escritura; ELSE # k== CLOSE procesa el cierre; more=false; send access_reply[clientId] (results); } Sistemas Distribuidos Clase 1

Este ejemplo de interacción entre clientes y servidores se denomina continuidad conversacional. (del OPEN al CLOSE). Si el lenguaje soportara creación dinámica de procesos y canales, el número N de file servers puede adaptarse a los requerimientos del sistema real. Otro esquema de solución sería un file server por disco. Analicemos conceptualmente las diferencias... Otra solución: Sun Netwok File System: OPEN ===> adquirir un descriptor completo del file. Las operaciones sucesivas son RPC trasmitiendo el descriptor. (ventajas y desventajas) Sistemas Distribuidos Clase 1

Mecanismos de comunicación y sincronización entre procesos.

Presentaciones similares

Presentación del tema: "Mecanismos de comunicación y sincronización entre procesos."— Transcripción de la presentación:

Presentaciones similares

Sobre el proyecto

Feedback

Iniciar la sesión

Autorizarse a través de una red social:

Mecanismos de comunicación y sincronización entre procesos.

Presentaciones similares

Presentación del tema: "Mecanismos de comunicación y sincronización entre procesos."— Transcripción de la presentación:

Presentaciones similares

Sobre el proyecto

Feedback