Sistemas Operativos INF - 151

Transcripción

1 Sistemas Operativos INF MODULO II. PROCESOS 2.3 Concurrencia y Exclusión Mutua 12/10/07 Resumen preparado por Miguel Cotaña

2 El diseño de SO están relacionados con la gestión de procesos e hilos: Multiprogramación. Gestión de múltiples procesos dentro de un sistema monoprocesador. Multiprocesamiento. Gestión de múltiples procesos dentro de un multiprocesador. Procesamiento distribuido. Gestión de múltiples procesos que ejecutan sobre múltiples sistemas de cómputo distribuidos. 2

3 Principios de concurrencia Según el diccionario, concurrencia es: El Acaecimiento o concurso de varios sucesos en un mismo tiempo Concurrencia es el conjunto de actividades que se desarrollan de forma simultánea En computación cada una de esas actividades se suele llamar proceso 3

4 Comunicación entre procesos. Compartición y competencia por los recursos. Sincronización de la ejecución de varios procesos. Asignación del tiempo de procesador a los procesos. 4

5 Programa y proceso Puede haber múltiples procesos en ejecución que correspondan al mismo programa Ejemplo: Un servidor de aplicaciones donde reside un navegador de Internet y existen varios usuarios ejecutando ese navegador 5

6 Dos procesos serán concurrentes cuando exista solapamiento (intercalado) en la ejecución de sus instrucciones Tres procesos (independientes) concurrentes ejecutándose al mismo tiempo sobre el sistema operativo (cada proceso corresponde a una instancia del programa del navegador) 6

7 Un Programa al ponerse en ejecución, puede dar lugar a más de un proceso, c/u de ellos ejecutando una parte del programa Por ejemplo: El programa del navegador de Internet formado por n procesos: uno que controla las acciones del usuario con la interfaz, otro que hace las peticiones al servidor, etc. 7

8 El Proceso p1.1 y el Proceso p1.2 pueden estar colaborando para hacerle la vida más fácil al usuario El proceso p1.2 y el proceso p2.2 pueden estar compitiendo para acceder a disco 8

9 En un sistema multiprogramado único, los procesos se entrelazan en el tiempo para ofrecer la apariencia de ejecución simultánea tiempo Proceso 1 bloqueando ejecutando Proceso 2 Proceso 3 Intercalado (multiprogramación, un procesador) 9

10 En un sistema de múltiples procesadores no sólo es posible entrelazar la ejecución de múltiples procesos sino también solaparlas tiempo Proceso 1 Proceso 2 Proceso 3 Intercalado y solapamiento (multiproceso; 2 procesadores) 10

11 El entrelazado y el solapamiento son técnicas que pueden verse como ejemplos de procesamiento concurrente. En el caso de un monoprocesador, los problemas surgen de una característica básica de los sistemas multiprogramados: no puede predecirse la velocidad relativa de ejecución de los procesos. Ésta depende de la actividad de los otros procesos, de la forma en que el SO maneja las interrupciones y de las políticas de planificación del SO. 11

12 Se plantean las siguientes dificultades: 1) La compartición de recursos globales está cargada de peligros. Por ejemplo, si 2 procesos utilizan ambos la misma variable global y ambos realizan lecturas y escritura sobre esa variable, entonces el orden en que se ejecuten las lecturas y escrituras es crítico 12

13 2) Para el SO es complicado gestionar la asignación de recursos óptimamente. Por ejemplo, un proceso puede solicitar el uso de un canal concreto de E/S, y serle concedido el control, y luego ser suspendido justo antes de utilizar ese canal. 3) Llega a ser muy complicado localizar errores de programación. 13

14 En un sistema multiprocesador, también se presentan todas las dificultades mencionadas void echo() ent = getchar(); sal = ent; putchar(sal); 14

15 Es necesario proteger las variables globales compartidas (así como otros recursos globales compartidos) y que la única manera de hacerlo es controlar el código que accede a la variable Hemos ido suponiendo de que se trata de un SO multiprogramado para un monoprocesador. En un sistema multiprocesador, aparecen los mismos problemas de recursos compartidos protegidos, y funcionan las mismas soluciones. 15

16 Supóngase que no hay mecanismo para controlar los accesos a la variable global compartida: Proceso P1 Proceso P2.. ent = getchar();... ent = getchar(); sal = ent; sal = ent; putchar(sal);.. putchar(sal);.. 16

17 En el caso de un sistema monoprocesador, el motivo por el que se tiene un problema es que una interrupción puede parar la ejecución de instrucciones en cualquier punto de un proceso. En un sistema multiprocesador, se tiene el mismo motivo y, además, puede suceder porque 2 procesos pueden estar ejecutando simultáneamente y ambos intentando acceder a la misma variable global. Sin embargo, la solución es la misma: controlar los accesos a los recursos compartidos. 17

18 Condición de carrera Una condición de carrera sucede cuando múltiples procesos o hilos leen y escriben datos de manera que el resultado final depende del orden de ejecución de las instrucciones en los múltiples procesos. Ejemplo1: Considere los procesos P1 y P2, que comparten las variables globales b y c, con valores iniciales b=1 y c=2. En algún punto de su ejecución, P1 ejecuta b=b+1 y en algún punto de su ejecución, P2 ejecuta c=b+c 18

19 Interacción de procesos Podemos clasificar las formas en que los procesos interaccionan en base al grado en que perciben la existencia de cada uno de los otros: Procesos que no se perciben entre sí. Son procesos independientes que no se pretende que trabajen juntos. Aunque los procesos no estén trabajando juntos, el SO necesita preocuparse de la competencia por recursos. 19

20 Procesos que se perciben indirectamente entre sí. Son procesos que no están necesariamente al tanto de la presencia de los demás mediante sus respectivos ID de procesos, pero que comparten accesos a algún objeto, como un buffer de E/S. Tales procesos exhiben cooperación en la compartición del objeto común Procesos que se perciben directamente entre sí. Capaces de comunicarse entre sí vía el ID del proceso. Tales procesos exhiben cooperación. 20

21 Competencia entre procesos por recursos Los procesos concurrentes entran en conflicto entre ellos cuando compiten por el uso del mismo recurso. No existe intercambio de información entre los procesos en competencia. Si 2 procesos desean ambos acceder al mismo recurso único, el SO reservará el recurso para uno de ellos y el otro tendrá que esperar. Por tanto, el proceso al que se le deniega el acceso será ralentizado 21

22 En el caso de procesos en competencia, deben afrontarse 3 problemas de control: Exclusión mutua Interbloqueo Inanición Recurso crítico Sección crítica 22

23 Suponiendo que 2 o más procesos requieren acceso a un recurso (impresora) único no compartible. Durante la ejecución, cada proceso estará enviando mandatos al dispositivo de E/S, recibiendo información de estado, enviando o recibiendo datos. Tal recurso es un recurso crítico, y a la porción del programa que lo utiliza como la sección crítica del programa 23

24 La aplicación de la exclusión mutua crea 2 problemas: interbloqueo e inanición. El interbloqueo se define como: El Bloqueo permanente de un conjunto de procesos que ya sea, compiten por los recursos del sistema o bien se comunican unos con otros. 24

25 Situación en la que se encuentran un conjunto de procesos, (al menos dos), tal que cada proceso del conjunto espera la ocurrencia de un evento que sólo puede ser provocado por otro proceso del mismo conjunto. Todos los interbloqueos suponen demandas contradictorias de recursos por parte de 2 o más procesos. 25

26 Un conjunto de procesos está en bloqueo mutuo/interbloqueo si cada proceso del conjunto está esperando un evento que sólo otro proceso del conjunto puede causar. Los bloqueos ocurren en entornos multiprogramación, cuando varios procesos compiten por un número limitado de recursos. El bloqueo ocurre cuando un proceso monopoliza el acceso a un recurso y requiere otro recurso que ha sido ya asignado a un segundo proceso, que a su vez necesita el recurso monopolizado por el primer proceso. 26

27 Ejemplos: Ley del estado de Kansas: Si dos trenes se aproximan uno al otro en un cruce, ambos harán alto total y ninguno arrancará de nuevo hasta que el otro se haya ido 2 personas llamándose por teléfono mutuamente 27

28 28

29 29

30 Recursos: Son los objetos otorgados/usados por los procesos en un instante dado. Secuencia de eventos necesarios para utilizar un recurso: 1. Solicitar el recurso 2. Utilizar el recurso 3. Liberar el recurso 30

31 De acuerdo a su estructura real hay 2 tipos: Físicos (dispositivos de HW): Memoria, dispositivos. etc. Lógicos (elemento de información): archivos, semáforos, cerrojos, mensajes, señales, etc. De acuerdo a su uso hay 2 tipos: Reutilizables Consumibles 31

32 Recursos Reutilizables: Es aquél que puede ser usado por un proceso y no se agota con el uso. Los procesos obtienen recursos que liberan posteriormente para que otros procesos las reutilicen. Ejemplo: Procesadores, canales E/S, memoria principal y secundaria, archivos, BD, etc, 32

33 Recursos Consumibles Es aquél que puede ser creado (producido) y destruido (consumido). Ej: Interrupciones, señales, mensajes, etc. 33

34 Un ejemplo de inanición: Suponiendo 3 procesos (P1,P2, P3) requieren todos accesos periódicos al recurso R. Si P1 está en posesión del recurso y P2 y P3 están ambos retenidos, esperando por ese recurso. Cuando P1 termine su sección crítica, debería permitírsele acceso a R a P2 o P3. Suponiendo que el SO le concede acceso a P3 y que P1 solicita acceso otra vez antes de completar su sección crítica. Si el SO le concede acceso a P1 después de que P3 haya terminado, y posteriormente concede alternativamente acceso a P1 y P3, entonces a P2 puede denegársele indefinidamente el acceso al recurso, aunque no suceda interbloqueo 34

35 En términos abstractos la exclusión mutua, se puede ilustrar: /*PROCESO 1 */ Void P1 while (true) /* código anterior */; entrarcritica (Ra); /* sección crítica */; salircritica (Ra); /* código posterior */; /*PROCESO 2 */ Void P1 while (true) /* código anterior */; entrarcritica (Ra); /* sección crítica */; salircritica (Ra); /* código posterior */; /*PROCESO n */ Void P1 while (true) /* código anterior */; entrarcritica (Ra); /* sección crítica */; salircritica (Ra); /* código posterior */; 35

36 Cooperación entre procesos vía compartición Cubre procesos que interaccionan con otros procesos sin tener conocimiento explícito de ellos. Por ejemplo, múltiples procesos pueden tener acceso a variables compartidas o a BD. Los procesos pueden usar y actualizar los datos compartidos sin referenciar otros procesos pero saben que otros procesos pueden tener acceso a los mismos. Así, los procesos deben cooperar para asegurar que los datos compartidos son manipulados adecuadamente. 36

37 Tomando en cuanta que los datos están contenidos en recursos (dispositivos, memoria), los problemas de exclusión mutua, interbloqueo e inanición están presentes de nuevo. La única diferencia es que los datos individuales pueden ser accedidos de dos maneras diferentes, lectura y escritura, y sólo las operaciones de escritura deben ser mutuamente exclusivas 37

38 Por encima de estos problemas, surge un nuevo requisito: el de la coherencia de datos Ejemplo: P1 y P2 que comparten datos a y b que deben cumplir a=b P1 P2 (I 11 ) a = a + 1; (I 21 ) b = b * 2; (I 12 ) b = b + 1; (I 22 ) a = a * 2; Supóngase ahora la secuencia de ejecución siguiente: (I 11, I 21 I 12 I 22 ) Sí el estado es inicialmente consistente, cada proceso tomado por separado dejará los datos compartidos en un estado consistente. 38

39 Cooperación entre procesos vía comunicación En los 2 casos tratados, cada proceso tiene su propio entorno aislado que no incluye a los otro procesos. Las interrelaciones entre los proceso son indirectas. En ambos casos hay cierta compartición. En el caso de la competencia hay recursos compartidos sin ser conscientes de los otros procesos. En el segundo caso, hay compartición de valores y aunque cada proceso no es explícitamente consciente de los demás procesos, es conciente de la necesidad de mantener la integridad de datos. 39

40 Cuando los procesos cooperan vía comunicación, en cambio, los diversos procesos involucrados participan en un esfuerzo común que los vincula a todos ellos. La comunicación proporciona una manera de sincronizar o coordinar actividades varias. Típicamente, la comunicación se fundamenta en mensajes de algún tipo. Las primitivas de envío y recepción de mensajes deben ser proporcionadas como parte del lenguaje de programación o por el núcleo del SO. 40

41 Requisitos para la exclusión mutua Cualquier mecanismo o técnica que vaya a proporcionar exclusión mutua debería contemplar los siguientes requisitos: 1. La exclusión mutua debe hacerse cumplir: sólo se permite un proceso al tiempo dentro de su sección crítica, de entre todos los procesos que tienen secciones críticas para el mismo recurso compartido. 2. Un proceso que se pare en su sección no crítica debe hacerlo sin interferir con otros procesos. 41

42 3. No debe ser posible que un proceso que solicite acceso a una sección crítica sea postergado indefinidamente: ni interbloqueo ni inanición. 4. Cuando ningún proceso esté en una sección crítica, a cualquier proceso que solicite entrar en su sección crítica debe permitírsele entrar sin demora. 5. No se hacen suposiciones sobre las velocidades relativas de los procesos ni sobre el número de procesadores. 6. Un proceso permanece dentro de su sección crítica sólo por un tiempo finito. 42

43 Exclusión mutua: soporte hardware Deshabilitar interrupciones En una máquina monoprocesador, los procesos concurrentes no pueden solaparse, sólo pueden entrelazarse. Es más, un proceso continuará ejecutando hasta que invoque un servicio del SO o hasta que sea interrumpido. Por tanto, para garantizar la exclusión mutua, basta con impedir que un proceso sea interrumpido 43

44 Un proceso puede cumplir la exclusión mutua, de la siguiente forma: While (true) /*deshabilitar interrupciones */; /*sección crítica */; /*habilitar interrupciones */; /*resto */; 44

45 Instrucciones máquina especiales A un nivel de hardware, el acceso a una posición de memoria excluye cualquier otro acceso a la misma posición. Con este fundamento, los diseñadores de procesadores han propuesto varias instrucciones máquina que llevan a cabo 2 acciones atómicamente, como leer y escribir o leer y comprobar, sobre una única posición de memoria con un único ciclo de búsqueda de instrucción. 45

46 Durante la ejecución de la instrucción, el acceso a la posición de memoria se le bloquea a toda otra instrucción que referencie esa posición. Típicamente, estas acciones se realizan en un único ciclo de instrucción. Se consideran: Instrucción Test and Set Instrucción Exchange 46

47 Instrucción Test and Set (comprueba y establece). Esta instrucción puede definirse como: boolean testset (int i) if (i==o) i=1; return true; else return false; 47

48 /* programa exclusión mutua */ const int n= /* número de procesos */; int cerrojo; void P(int i) while (true) while (!testset (cerrojo)) /* no hacer nada */; /* sección crítica */; cerrojo=0; /* resto */ void main() cerrojo=0; paralelos (P(1), P(2),..,P(n)); 48

49 Instrucción Exchange. La instrucción exchange como: (intercambio) puede definirse void exchange (int registro, int memoria) int temp; temp = memoria; memoria = registro; registro = temp; 49

50 /* programa exclusión mutua */ const int n= /* número de procesos */; int cerrojo; void P(int i) int llavei = 1; while (true) do exchange (llavei, cerrojo) while (llavei!=0); /* sección crítica */; exchange (llavei, cerrojo); /* resto */ void main() cerrojo=0; paralelos (P(1), P(2),..,P(n)); 50

51 Propiedades de la solución instrucción máquina. El uso de una instrucción máquina especial para conseguir exclusión mutua tiene ciertas ventajas: Es aplicable a cualquier número de procesos sobre un procesador único o multiprocesador de MP compartida. Es simple y, por tanto, fácil de verificar. Puede ser utilizado para dar soporte a múltiples secciones críticas: cada sección crítica puede ser definida por su propia variable. 51

52 Entre las desventajas serias: Se emplea espera activa. Mientras un proceso está esperando para acceder a una sección crítica, continúa consumiendo tiempo de procesador. Es posible la inanición. Cuando un proceso abandona su sección crítica y hay más de un proceso esperando, la selección del proceso en espera es arbitraria. Es posible el interbloqueo. 52

53 Semáforos Una de las soluciones más famosas y significantes del problema de cooperación entre procesos paralelos fue la propuesta de Dijkstra. Su solución introdujo un nuevo tipo de variables, llamadas semáforos, y 2 operaciones especiales. 53

54 La propuesta de Dijkstra es el resultado de su crítica a las soluciones con espera activa. Y dice, cuando un proceso está ejecutando las instrucciones de la sección crítica, ningún otro puede estar en la sección. Además, si alguno quiere entrar, tiene que esperar hasta que termine la ejecución del proceso en turno. 54

55 Durante este tiempo nada se puede cambiar, entonces no tiene caso que el proceso esté esperando, repitiendo inútilmente la revisión del valor de una variable (o más). Mejor que descanse abriendo la posibilidad de que el tiempo de procesador lo aproveche quien lo necesite verdaderamente. La idea básica es la suspensión de los procesos que no pueden entrar y su reactivación, cuando algún proceso sale de la sección. 55

56 Dos o más procesos pueden cooperar por medio de simples señales, tales que un proceso pueda ser obligado a parar en un lugar específico hasta que haya recibido una señal específica. Cualquier requisito complejo de coordinación puede ser satisfecho con la estructura de señales apropiada 56

57 Para la señalización, se utiliza la variable semáforo. Para transmitir una señal vía el semáforo s, el proceso ejecutará la primitiva semsignal(s). Para recibir una señal vía el semáforo s, el proceso ejecutará la primitiva semwait(s); si la correspondiente señal no se ha transmitido todavía, el proceso se suspenderá hasta que la transmisión tenga lugar. 57

58 Las 3 operaciones son: 1. Un semáforo puede ser inicializado a un valor no negativo 2. La operación semwait decrementa el valor del semáforo. Si el valor pasa a ser negativo, entonces el proceso que está ejecutando semwait se bloquea. En otro caso, el proceso continúa su ejecución. 3. La operación SemSignal incrementa el valor del semáforo. Si el valor es menor o igual que cero, entonces se desbloquea uno de los procesos bloqueados en la operación semwait. 58

59 Struct semaphore int cuenta; queuetype cola; void semwait(semaphore s) s.cuenta--; if (s.cuenta<0) poner este proceso en s.cola; bloquear este proceso; void semsignal(semaphore s) s.cuenta++; if (s.cuenta <= 0) extraer un proceso P de s.cola; poner el proceso P en la lista de listos; Definición de primitivas del semáforo 59

60 Un semáforo binario, define 3 operaciones 1. Un semáforo binario puede ser de inicio 0 o 1 2. La operación semwaitb comprueba el valor del semáforo. Si el valor es cero, entonces el proceso que está ejecutando samwaitb se bloquea. Si el valor es 1, entonces se cambia el valor a cero y el proceso continúa su ejecución. 3. La operación semsignalb comprueba si hay algún proceso bloqueado en el semáforo. Si lo hay, entonces se desbloquea uno de los procesos bloqueados en la operación semwaitb. Si hay bloqueados, entonces el valor del semáforo se pone a uno. 60

61 Struct binary_semaphore enum cero, uno valor; queuetype cola; void semwaitb(binary_semaphore s) if (s.valor == 1) s.valor = 0; else poner este proceso en s.cola; bloquear este proceso; void semsignalb(binary_semaphore s) if (esta_vacia(s.cola)) s.valor = 1; else extraer un proceso P de s.cola; poner el proceso P en la lista de listos; Def. de prim. del semáforo binario o mutex 61

62 El orden en que son extraídos de la cola es FIFO: el proceso que lleve más tiempo bloqueado es el primero en ser extraído de la cola; un semáforo cuya definición incluye esta política se denomina semáforo fuerte. Un semáforo que no especifica el orden en que los procesos son extraídos de la cola es un semáforo débil. 62

63 Ejemplo de mecanismo de semáforo fuerte: 1 procesador A s = 1 C D B Cola de bloqueados semáforo Cola de listos 2 B s = 0 A C D 3 Cola de bloqueados D Cola de listos s = -1 A C Cola de bloqueados Cola de listos 63

64 4 D s = 0 B A C Cola de bloqueados Cola de listos 5 C s = 0 D B A Cola de bloqueados Cola de listos 6 D 7 B A Cola de bloqueados C s = -3 D Cola de listos B A Cola de bloqueados s = -2 Cola de listos C 64

65 Exclusión mutua usando semáforos El problema de la exclusión mutua se puede resolver correctamente usando los semáforos con sus respectivas operaciones. Los semáforos fuertes garantizan estar libres de inanición, mientras que los semáforos débiles no. Se asumirán semáforos fuertes dado que son más convenientes y porque ésta es la forma típica del semáforo proporcionado por los SO. 65

66 /* programa exclusión mutua */ const int n= /* número de procesos */; semafore s = 1; void P(int i) while (true) semwait(s); /* sección crítica */; semsignal(s); /* resto */ void main() paralelos (P(1), P(2),..,P(n)); 66

67 El problema productor/consumidor En algún sistema están trabajando en paralelo N (N>=1) procesos de productores y K(K>=1) procesos consumidores. Cada proceso productor está preparando una porción de datos, mandándola después para que la pueda usar alguno de los consumidores. Cada proceso consumidor recibe una porción de datos y la consume 67

68 Productor: while (true) /*preparación de datos*/; /*envio de datos*/; Consumidor: while (true) /*recepción de datos*/; /*consumo de datos*/; 68

69 Es decir, hay uno o más procesos generando algún tipo de datos (registros, caracteres) y poniéndolos en un buffer. Hay un único consumidor que está extrayendo datos de dicho buffer de uno en uno. El sistema está obligado a impedir la superposición de las operaciones sobre los datos. Asumiremos que el buffer es infinito (buffer no restringido) y consiste en un vector de datos: 69

70 Productor: while (true) /*producir dato v */; b[entra] = v; entra++; Consumidor: while (true) while (entra <= sale) /*no hacer nada*/; w = b[sale]; sale++ /*consumir dato w */ 70

71 /* programa productor consumidor con */ /* buffer infinito usando semáforos binarios */ int n; binary_semaphore s = 1; binary_semaphore retardo = 0; void productor() while (true) producir(); semwaitb(s); anyadir(); n++; if (n==1) semsignalb(retardo); semsignalb(s) 71

72 void consumidor() int m; /* una variable local */ semwaitb(retardo); while (true) semwaitb(s); extraer(); n--; m = n; semsignalb(s); consumir(); if (m==0) semwaitb(retardo); void main() n = 0; paralelos (productor, consumidor); 72

73 Monitores Los semáforos proporcionan una herramienta potente y flexible para conseguir la exclusión mutua y para la coordinación de procesos. Sin embargo, puede ser difícil producir un programa correcto utilizando semáforos. La dificultad es que las operaciones semwait semsignal pueden estar dispersas a través de un programa y no resulta fácil ver el efecto global de estas operaciones sobre los semáforos a los que afectan. y 73

74 El monitor es una construcción del lenguaje de programación que proporciona una funcionalidad equivalente a la de los semáforos pero es más fácil de controlar. La construcción monitor ha sido implementada en cierto número de lenguajes de programación, incluyendo Pascal Concurrente, Pascal-Plus, Modula-2, Modula-3 y Java. También ha sido implementada como una biblioteca de programa. 74

75 Monitor con señal Un monitor es un módulo software consistente en uno o más procedimientos, una secuencia de inicialización y datos locales. Las características son: Las variables locales de datos son solo accesibles por los procedimientos del monitor y no por ningún procedimiento externo Un proceso entra en el monitor invocando uno de sus procedimientos 75

76 Sólo un proceso puede estar ejecutando dentro del monitor al tiempo; cualquier otro proceso que haya invocado al monitor se bloquea, en espera de que el monitor quede disponible Las 2 primeras características guardan semejanza con las de los objetos en software OO. 76

77 /* programa productor consumidor usando monitor */ monitor bufferacotado; char buffer[n]; int dentro, fuera; int cuenta; cond nolleno, novacio; void anyadir(char x) if (cuenta == N) cwait(nolleno); buffer[dentro] = x; dentro = (dentro +1) % N; cuenta++; csignal(novacio); Void extraer (char x) if (cuenta == 0) cwait(novacio); x = buffer[fuera]; fuera = (fuera + 1) % N; cuenta--; csignal(no lleno); dentro = 0; fuera = 0; cuenta = 0; 77

78 void productor() char x; while (true) producir(x); anyadir(x); void consumidor() char x; while (true) extraer(x); consumir(x); Void main() paralelos (productor, consumidor); 78

79 Paso de mensajes Cuando los procesos interaccionan entre sí, deben satisfacerse 2 requisitos fundamentales: sincronización y comunicación. Los proceso necesitan ser sincronizados para conseguir exclusión mutua. Los procesos cooperantes pueden necesitar intercambiar información. Un enfoque que proporciona ambas funciones es el paso de mensajes. 79

80 El paso de mensajes tiene la ventaja añadida de que se presta a ser implementado tanto en sistemas distribuidos como en multiprocesadores de memoria compartida y sistemas monoprocesador. La funcionalidad real del paso de mensajes se da en forma de un par de primitivas: send(destino, mensaje) receive(origen, mensaje) 80

81 Formato de mensaje S1 S1 PUERTO R1 PUERTO R1 a) uno a uno Sn b) Muchos a uno R1 S1 R1 S1 BUZON BUZON c) uno a muchos Sn Sn d) Muchos a muchos Rn 81