Tema 8: Sincronización y Comunicación

Tema 8: Sincronización y Comunicación
Sistemas Operativos Tema 8: Sincronización y Comunicación

Índice: Monitores Mensajes Cooperación Mediante Mensajes Mensajes en Red Equivalencias entre primitivas Tema 8: Sincronización y Comunicación 2

1. Monitores Tema 8: Sincronización y Comunicación Semáforos: Artefactos del SO que se emplean como mecanismos de sincronización ¡Pero no contienen la lógica de coordinación! Monitores (Hoare, 1.974): Estructura del lenguaje de programación Encapsulan la lógica de coordinación junto con los mecanismos Aclara que monitores no pertenecen a SO, sino a lenguaje de programación.

1. Monitores Tema 8: Sincronización y Comunicación Definición: Estructura del lenguaje compuesta por: Datos locales a la estructura Subprogramas (métodos) que pueden acceder a dichos datos Cumplen: Interfaz pública viene dada por los métodos (los datos privados) Se garantiza que en cada momento sólo puede haber un proceso activo en algún método del monitor. Permiten organizar procesos en espera mediante variables de condición + primitivas de suspensión y reanudación. En realidad, cuando se dice que sólo puede haber un proceso activo dentro de algún método del monitor, la idea es que sólo puede haber un proceso ejecutando algún método del monitor. Esto se aclarará en la diapositiva 8.

1. Monitores Tema 8: Sincronización y Comunicación monitor mimonitor { private: public: } Datos y métodos locales, variables de condición Aclara que esta sintaxis es abstracta y no tiene por qué corresponderse con ningún lenguaje de programación Todo lo que se cuente vale tanto para procesos como para hilos Conclusión hasta aquí: los monitores garantizan la exclusión mutua en la ejecución de sus métodos. Ojo con el paso a la siguiente diapositiva (wait()/signal()/problema de la reanudación) que el cambio no se nota. void metodo1 () { } void metodo2 () { } Métodos públicos

1. Monitores Tema 8: Sincronización y Comunicación monitor mimonitor { private: public: } Datos y métodos locales, variables de condición condition C; No olvides comentar que cada variable de condición tiene asociada una lista de procesos bloqueados en ella, y que signal() reanuda a uno cualquiera. signal() sobre una variable de condición sin procesos bloqueados no tiene efectos. Un monitor puede declarar tantas variables de condición como necesite Termina enunciando el problema de la reanudación. void metodo1 () { } void metodo2 () { } Métodos públicos if (tengo_que_esperar()) wait(C); signal(C);

1. Monitores Tema 8: Sincronización y Comunicación Reanudación mediante signal(): signal() actúa como return() (Brinch Hansen, 1975) Simple, pero irritante para los programadores Prioridad a proceso reanudado (Hoare, 1974) Proceso que hace signal() se detiene hasta que proceso reactivado deja libre monitor. Si proceso reactivado hace otro signal(): lista de procesos pendientes de reactivación. Prioridad a proceso que hace signal() (Lampson y Redell, 1980) Proceso puede hacer varios signal(): lista de procesos pendientes de reactivación Puede haber vuelto a cambiar la condición de espera: if (condicion) wait(C); → while(condicion) wait(C); ¿De entre la segunda y tercera opción cuál es mejor? Pues la tercera provoca un menor número de conmutaciones.

1. Monitores Tema 8: Sincronización y Comunicación Productor/Consumidor con monitores: … public: void Almacenar (tipo dato) { if (cont==N) wait (lleno); almacenar_dato (dato); cont++; if (cont==1) signal (vacio); } tipo Extraer () { if (cont==0) wait (vacio); tipo resultado= extraer_dato (); cont--; if (cont==N-1) signal (lleno); return resultado; } } monitor prodCons { private: condition lleno, vacio; int cont= 0; tipo tabla[N]; int ins, ext= 0; void almacenar_dato (tipo dato) { tabla[ins]= dato; if (++ins == N) ins=0; } tipo extraer_dato () { tipo resultado= tabla[ext]; if (++ext==N) ext= 0; return resultado; } … void productor () { while(true) { tipo dato= producir_elemento(); ProdCons.Almacenar(dato); } } void consumidor() { while(true) { tipo dato= ProdCons.Extraer(); consumir(dato); } } ¿Cómo se usa todo esto? Destaca que el propio monitor encapsula: el propio recurso compartido su lógica de acceso la lógica de coordinación Haz notar también cómo programamos olvidándonos de la concurrencia. ¡No pueden haber condiciones de carrera, pues se garantiza la exclusión mutua!

1. Monitores Tema 8: Sincronización y Comunicación “Inconvenientes”: Espacio protegido para ser accedido sólo de la forma que está autorizado Problema del compilador. Riesgo de interbloqueo si desde un método de un monitor se llama a otro El interbloqueo no depende de los mecanismos empleados, sino de la lógica. Métodos diseñadados para unas aplicaciones, talvez no sean los más adecuados para otras Si no sabes diseñar software reutilizable, estudia ISWx No todos los lenguajes los soportan Java, Modula3, Modula2, Pascal Concurrente… Librería De estos inconvenientes, sólo el cuarto es relevante: Que a la zona privada del monitor sólo se pueda acceder desde los métodos del mismo se encarga el compilador, que usará si es necesario los mecanismos del SO pertinentes. Si puede ser complicado detectar una situación que pueda dar lugar a interbloqueos mediante monitores, imagínate mediante semáforos, por ejemplo. La construcción de software reutilizable depende del diseño, y precisamente estructuras como monitores facilitan la construcción de software reutilizable. La cuarta es verdad que es un problema.

1. Monitores Tema 8: Sincronización y Comunicación Monitores en el lenguaje Java: Cada objeto Java garantiza la exclusión mutua entre sus métodos declarados como synchronized. No hay variables de condición  wait(C) → Método wait() heredado de clase Object. signal(C) → Métodos notify()/notifyAll() heredados de clase Object: if (condicion) wait(C) → while(condicion) wait(); signal(C) → notifyAll(); Esto a título informativo, sólo si se va bien de tiempo.

2. Mensajes Tema 8: Sincronización y Comunicación Primitiva de sincronización y comunicación Fácil implementación Mecanismo empleado para coordinar componentes del sistema operativo en sistemas micronúcleo Fácil de portar a sistemas distribuidos Primitivas: Sobre detalles de cómo se implementan no vamos a discutir nada todavía pues depende de cosas que vamos a contar a continuación. send(destino, mensaje) receive(destino, mensaje) sendrec(dest_fuent, mensaje)

2. Mensajes Tema 8: Sincronización y Comunicación Destino y fuente Formas de transmisión Tipos de comunicación Longitud de los mensajes Aplazamiento indefinido Cosas que hay que detallar

2. Mensajes Tema 8: Sincronización y Comunicación Destino y fuente Formas de transmisión Tipos de comunicación Longitud de los mensajes Aplazamiento indefinido

2.1 Destino y fuente Tema 8: Sincronización y Comunicación Denominación Directa: destino y fuente son identificadores de procesos Valores especiales: BROADCAST ANY Denominación Indirecta: Recurso compartido especial en el sistema: buzón Los mensajes se leen y envían de/a buzones Buzones tienen asociado algún tipo de nombre denominación indirecta: Deben existir primitivas de creación y destrucción de buzones: Creat Box () y DestroyMailBox() Los buzones tienen el nombre externo con el que se “abren”, y una vez abiertos, se usan a través de un descriptor (similar a archivos). emisor receptor

2.1 Destino y fuente Tema 8: Sincronización y Comunicación Denominación Directa: Ventajas: simplicidad Inconvenientes: Procesos deben conocerse entre sí Equivalente a un único “buzón” por proceso (menos flexible) Denominación Indirecta: Ventajas: Flexibilidad Emisor y receptor no necesitan conocerse Fácil de portar a ambientes distribuidos Posibilidad de procesos intrusos (click) para ilustrar lo de la flexibilidad Lo de los procesos intrusos se refiere a que puedan haber procesos que escriban mensajes en un buzón si derecho a hacerlo, o que se lleven mensajes de un buzón del que no deberían leer. Eso se soluciona mediante permisos de acceso. P1 P3 P2 P4

2.2 Formas de Transmisión Tema 8: Sincronización y Comunicación Por copia Directa Indirecta Por referencia Global Por copia en caso de escritura (COW)

2.2 Formas de Transmisión Tema 8: Sincronización y Comunicación Transmisión por copia directa Mensaje se copia de espacio de emisor a espacio de receptor Inconvenientes tiempo empleado en copiar ¿Y si receptor no está en memoria? emisor receptor

2.2 Formas de Transmisión Tema 8: Sincronización y Comunicación Transmisión por copia indirecta Mensaje se copia de espacio de emisor a espacio de SO, y de ahí a espacio de receptor Inconvenientes: tiempo empleado en copiar se multiplica por dos ¿Y si espacio SO se llena? Sistema Operativo emisor receptor

2.2 Formas de Transmisión Tema 8: Sincronización y Comunicación Transmisión por referencia directa Lo que se copia es un puntero al mensaje Inconvenientes: Un puntero fuera de su espacio de memoria puede… No tener sentido Constituir un intento de violación del sistema de protección Mensaje se convierte en recurso compartido Justifica la transmisión por referencia en que ya no es necesario copiar el mensaje, y que los punteros normalmente son pequeños (4 bytes, típicamente). Lo de que el mensaje se convierta en recurso compartido significa… Emisor no puede alterar mensaje, al menos hasta que lo haya procesado receptor Receptor tampoco debe modificar mensaje, al menos sin avisar emisor Si hay memoria virtual, el mensaje no se podrá paginar emisor receptor

2.2 Formas de Transmisión Tema 8: Sincronización y Comunicación Transmisión por referencia global Emisor crea mensaje en espacio de SO, y se copia a espacio de receptor un puntero al mismo Receptor asume responsabilidad de liberar mensaje Inconvenientes: ¿y si espacio compartido se llena? ¿y si receptor olvida liberar mensaje? Sistema Operativo emisor receptor

2.2 Formas de Transmisión Tema 8: Sincronización y Comunicación Transmisión por copia en caso de escritura El mensaje sólo se copia si se modifica por emisor o receptor Necesitamos colaboración del hardware: mecanismos de protección de memoria. Recalca que la copia del mensaje se retrasa hasta el momento en que es imprescindible (posiblemente, nunca) emisor receptor

2.3 Tipos de Comunicación Tema 8: Sincronización y Comunicación Tanto emisión como recepción pueden ser: Síncrona Asíncrona Emisión síncrona: Emisor se bloquea hasta que receptor recibe mensaje Recepción síncrona: Receptor se bloquea hasta recibir mensaje Emisión o recepción asíncrona: No hay bloqueos ¡No confundir asíncrona con no bloqueante! Lo más habitual: Recepción síncrona Emisión asíncrona

2.3 Tipos de Comunicación Tema 8: Sincronización y Comunicación Consecuencia de emisión asíncrona con copia intermedia: emisor receptor Recuerda que al limitar el espacio por procesos lo normal es programar una histéresis Gestión del espacio de las colas: En espacio de procesos En espacio de Sistema Operativo Para evitar llenar espacio: Limitar espacio o número de mensajes por proceso

2.3 Tipos de Comunicación Tema 8: Sincronización y Comunicación Utilidad de recepción no bloqueante: Procesos que deben hacer algo mientras no reciban mensajes Procesos que pueden recibir mensajes a través de varios buzones Explica aquí que las operaciones que permiten averiguar el nº de mensajes que hay en un buzón no sirven para implementar recepciones no bloqueantes. Cuenta qué pasa si varios procesos comparten un buzón y efectúan la lectura de esta forma: If(!buzon_vacio(b)) receive(b, &msg); receptor

2.4 Longitud de los mensajes Tema 8: Sincronización y Comunicación Tipos de mensajes: De longitud fija De longitud variable Longitud Variable Ventajas: Mayor flexibilidad Inconvenientes: complica implementación Si transferencia por referencia: distintos tamaños de ventana Si transferencia por copia: tiempo de transmisión variable Si colas de mensajes: no se pueden implementar con tablas Recuerda que con mensajes de longitud fija, aparte de la incomodidad que pueda suponer fragmentar la información a transferir, se desperdicia memoria pues en raras ocasiones dicha información tendrá una longitud múltiplo del tamaño del mensajes y el último mensaje no irá completo.

2.5 Aplazamiento indefinido Tema 8: Sincronización y Comunicación Aplazamiento indefinido en el tiempo: Procesos que esperan para siempre… Recibir un mensaje que nunca llegará Entregar un mensaje que nunca se recogerá Aplazamiento indefinido de mensajes: Mensajes que nunca serán recogidos Causa: procesos que Abortan Terminan

2.5 Aplazamiento indefinido Tema 8: Sincronización y Comunicación Soluciones: Denominación directa: Es trivial determinar si proceso compañero ha abortado o terminado Denominación indirecta: Si buzón tiene asociado permisos, se puede comprobar si hay procesos en el sistema que puedan leer o escribir en él Comunicación asíncrona: Siempre puede aplazar mensajes Solución: protocolos de confirmación (equivale a síncrona)

3. Cooperación Mediante Mensajes Tema 8: Sincronización y Comunicación Usaremos: Denominación Indirecta (buzones) Emisión Asíncrona Recepción Síncrona Por cada recurso compartido, un buzón B con un mensaje inicialmente Secciones críticas asociadas al recurso: Protocolo de entrada: receive(B,msg) Protocolo de salida: send(B, msg) ¡Mensaje actúa como testigo! Comenta que, en general, un buzón con N mensajes, en el que la lectura es síncrona y la lectura es asíncrona es funcionalmente equivalente a un semáforo con valor inicial N en el contador.

3. Cooperación Mediante Mensajes Tema 8: Sincronización y Comunicación Productor/Consumidor con mensajes while(true) { msg= producir_elemento(); send (datos, msg); } productor Una primera idea avocada al fracaso: no hay control de flujo En el ejemplo: productor mucho más rápido que consumidor Ni siquiera es necesario que productor más rápido: bastaría con que en una ranura de tiempo productor pudiese llenar el buzón while(true) { receive(datos, &msg); consumir_elemento(msg); } consumidor datos

3. Cooperación Mediante Mensajes Tema 8: Sincronización y Comunicación Productor/Consumidor con mensajes datos while(true) { msg= producir_elemento(); receive (sync, &ms); send (datos, msg); } productor while(true) { receive(datos, &msg); send(sync, msg); consumir_elemento(msg); } consumidor sync

4. Mensajes en Red Tema 8: Sincronización y Comunicación Se pueden coordinar mediante mensajes procesos en diferentes máquinas Hay que replantear algunos problemas, y tratar otros que aparecen: Identificación destino/remitente Fiabilidad transmisión Interpretación de los datos

4. Mensajes en Red Tema 8: Sincronización y Comunicación Identificación destino/remitente Denominación directa: no es viable ¿Qué PID tiene el proceso destino en la otra máquina? ¿Es único ese PID? ¿De qué tipo es el PID? (depende de SO) Con respecto a asociar nombre lógico al nombre físico, comenta que es muy similar al DNS. Si un buzón cambia físicamente de ubicación, el proceso que actúa como autoridad central debe ser informado de ello. Los procesos no dependen de dicha ubicación física. Denominación indirecta: ¿en qué máquina reside el buzón? ¡Procesos dependen de ubicación física del buzón! Autoridad central que asocia nombre lógico a nombre físico: mibuzon ↔

4. Mensajes en Red Tema 8: Sincronización y Comunicación Fiabilidad de la transmisión Al enviar información a través de una red… Puede no llegar Puede llegar alterada Puede llegar replicada Puede llegar en orden distinto al que se envió Los mensajes deben enviarse a través de una pila de protocolos Esta pila debe garantizar una calidad de servicio mínima: Los mensajes llegan sin alterar y en el orden en que se envían De lo contrario, al menos se nos informa de ello Si la calidad del servicio no es suficiente → será responsabilidad del servicio de mensajería implementar los protocolos que garanticen

4. Mensajes en Red Tema 8: Sincronización y Comunicación Interpretación de los datos Determinados datos pueden codificarse de distinta manera, según plataforma software o incluso procesador: Datos de más de un byte: Big endian (motorola, SPARC): byte más significativo en dirección más baja Little endian (intel): byte más significativo en dirección más alta Caracteres: distintas codificaciones: ANSI, ASCII, EBCDIC, UTF-8, UNICODE… Coma flotante: IEEE 754: precisión doble o simple

4. Mensajes en Red Tema 8: Sincronización y Comunicación Interpretación de los datos Solución 1: enviar junto a cada dato un identificador de tipo de dato Todo proceso debe conocer todo tipo de dato! Hay que enviar más información (identificadores de tipos) Solución 2: formatos estándar de red Cada proceso sólo conoce sus formatos y los de red Al enviar: convierte de formato nativo a formato de red Al recibir: se convierte de formato de red a formato nativo Doble conversión: ¡posiblemente innecesaria! No obstante, coste computacional muy pequeño.

5. Equivalencias entre primitivas Tema 8: Sincronización y Comunicación = = =

5. Equivalencias entre primitivas Tema 8: Sincronización y Comunicación Monitores con semáforos monitor mimonitor { private: condition C; public: void metodo1 () { … if (tengo_que_esperar()) wait(C); … } void metodo2 () { … signal(C); … } } semaforo excmut=CrearSemaforo(1); struct condition { int bloqueados; semaforo esp; /* = 0 */ }; struct condition C; Lo que aparece en las viñetas es código generado por el compilador para implementar el monitor. Comentar que la implementación de signal depende de cómo se haya implementado la reanudación. A modo de ejemplo, la que se muestra es la solución de Brinch Hansen consistente en que signal actúa como return. down(excmut); #define signal( /* condition* */ varcond) { if (c->bloqueados > 0) { c->bloqueados--; up(c->esp); } else up(excmut); return; } up(excmut); void wait(condition *varcond) { varcond->bloqueados++; up(excmut); down(varcond->esp); }; down(excmut); up(excmut);

5. Equivalencias entre primitivas Tema 8: Sincronización y Comunicación Buzones con semáforos semaforo esp; /* = 0 */ void send(buzon *b, mensaje *m) { down(b->excmut); if (b->num_mensajes == MSG_MAX)) { añadir(&b->esp_send,&esp); up(b->excmut); down(esp); } b->tabla[b->ins]=m; incrementar(&b->ins); b->nummensajes++; if (!lista_vacia(b->esp_rec)) { semaforo s=sacar_de_lista(&b->esp_rec); up(s); } else up(b->excmut); } semaforo esp; /* = 0 */ void receive(buzon *b, mensaje *m) { down(b->excmut); if (b->num_mensajes == 0) { añadir(&b->esp_receive,&esp); up(b->excmut); down(esp); } *m= b->tabla[b->ext]; incrementar(&b->ext); b->nummensajes--; if (!lista_vacia(b->esp_send)) { semaforo s=sacar_de_lista(&b->esp_send); up(s); } else up(b->excmut); } struct buzon { semaforo excmut; /* = 1 */ int nummensajes; listasem esp_send; listasem esp_rec; int ins, ext; mensaje[] tabla; } Esta implementación considera la posibilidad de que un buzón se pueda llenar: bloquea a procesos que intentan enviar si buzón está lleno. A cada proceso se le asocia un semáforo de espera inicialmente cerrado. Estructura del buzón: excmut: semáforo que garantiza exclusión mutua en acceso a buzón nummensajes: número de mensajes almacenado en buzón esp_send: lista de semáforos asociados a procesos en espera de poder enviar (si buzón lleno) esp_rec: lista de procesos en espera de poder recibir (si buzón vacío) ins, ext: índices de inserción y extracción tabla: tabla con los mensajes almacenados en buzón

5. Equivalencias entre primitivas Tema 8: Sincronización y Comunicación Semáforos con monitores monitor arr_semáforos { private: struct { int cont; condition esp; } S[N]; public: void down (int i) /* Down sobre el semáforo i-ésimo */ { if (--S[i].contador < 0) wait(S[i].esp); } void up (int i) /* Up sobre el semáforo i-ésimo */ { if(++S[i].contador <=0) signal(S[i].esp); } } Tan simple como programar la lógica de un semáforo. Por chulería, implementamos en vez de un semáforo, un array de semáforos.

5. Equivalencias entre primitivas Tema 8: Sincronización y Comunicación Buzones con monitores monitor buzon { private: int nummensajes; condition lleno, vacio; int ins, ext; mensaje[] tabla; public: void receive (mensaje *m) { if (num_mensajes == 0) wait (vacio); *m= tabla[ext]; incrementar(&ext); nummensajes--; signal (lleno); } void send(mensaje *m) { if (num_mensajes == MSG_MAX)) wait (lleno); tabla[ins]=*m; incrementar(&ins); nummensajes++; signal (vacio); } } Partimos de la misma idea que la implementación con semáforos, pero implementada con un monitor. La idea queda simplificada gracias a… que monitor garantiza exclusión mutua Variables de condición permiten organizar esperas de manera más intuitiva

5. Equivalencias entre primitivas Tema 8: Sincronización y Comunicación Semáforos con buzones servidor de semáforos cliente 1 identificación del semáforo contador del semáforo lista de los buzones de los procesos bloqueados cliente 2 Recuérdese que en cualquier caso, un buzón con N mensajes y las operaciones receive (síncrona) y send (asíncrona) es equivalente a un semáforo con contador N y operaciones up() y down(). Si se quiere tener un control detallado: sistema alternativo cliente/servidor: Los clientes envían sus peticiones de crear/destruir/down/up al servidor de semáforos, y esperan recibir una respuesta en su buzón. Es la espera de esta respuesta la que los bloquea en el down. Por cada semáforo creado, el servidor de semáforos almacena los atributos del susodicho: Identificación contador lista de buzones de los procesos bloqueados Operación down(id): Localizar el semáforo correspondiente si contador == 0 añadir buzón del remitente a la lista de procesos bloqueados en semáforo si no, decrementar contador operación up(id): si hay algún buzón en la lista de procesos bloqueados, extraer uno y enviarle el mensaje de confirmación que desbloquearse. si no, incrementar contador Problemas: semáforos así construidos no forman parte del SO -> no se heredan por parte de procesos -> dificultad de uso. Posibilidad de procesos intrusos identificación del semáforo referencia a buzón de proceso código de operación: CrearSemáforo destruirSemáforo Down Up valor inicial del contador, si operación es CrearSemáforo

5. Equivalencias entre primitivas Tema 8: Sincronización y Comunicación Monitores con buzones monitor nombre { private: condition C1, C2; public: void metodo1() { … if (me_espero()) wait(C1); … } void metodo1() { … signal(C1); … } } servidor de monitores nombre del monitor estado (libre u ocupado) lista de los buzones de procesos en espera de entrar por cada variable de condición: Nombre: C1 Lista de los buzones de los procesos bloqueados Nombre:C2 Idea calcada de la anterior (implementación de semáforos con buzones): proceso servidor A cada monitor se le asocia un buzón en el proceso cliente El compilador inserta código en el monitor que inserta un mensaje cada vez que: Va a entrar en un método del monitor Va a salir de un método del monitor Hace un wait() Hace un signal(). Al entrar en un método del monitor: envía mensaje (click) y espera respuesta. El proceso servidor, por cada monitor, almacena: Identificación (nombre) del monitor Estado del monitor (libre u ocupado) Lista de los buzones de procesos en espera de entrar Para cada variable de condición, se almacena su nombre y la lista de los buzones bloqueados en ella Al salir del monitor, se envía un mensaje al servidor que sirve para permitir la entrada a algún proceso que estuviese a la espera de ello. Al hacer un wait, se envía un mensaje al servidor y se espera respuesta. Esta espera bloquea al proceso. Al hacer un signal, se envía un mensaje al servidor y se utiliza para enviar un mensaje a algún proceso bloqueado en la misma variable de condición. nombre del monitor referencia a buzón de respuesta código de operación: Entrar en Monitor Salir de monitor signal wait nombre de variable de condición, si signal o wait.

Tema 8: Sincronización y Comunicación

Presentaciones similares

Presentación del tema: "Tema 8: Sincronización y Comunicación"— Transcripción de la presentación:

Presentaciones similares

Sobre el proyecto

Feedback

Iniciar la sesión

Autorizarse a través de una red social:

Tema 8: Sincronización y Comunicación

Presentaciones similares

Presentación del tema: "Tema 8: Sincronización y Comunicación"— Transcripción de la presentación:

Presentaciones similares

Sobre el proyecto

Feedback