Mdulo Administracin de recursos compartidos Corresponde a Mdulo

Módulo Administración de recursos compartidos: Corresponde a: • Módulo 4 de Notas Sobre Sistemas Operativos (Manual del alumno) • Capítulos 5 y 6 de STALLINGS • Capítulos 6 y 7 de SILBERSCHATZ • Capítulos 2 y 3 TANENBAUM Carlos NEETZEL cneetzel@sistemasoperativos. com. ar 1

Módulo Administración de recursos compartidos: CONTENIDO: • Conceptos de Concurrencia. • Conceptos de Sincronización entre Procesos. • Algoritmos de Sincronización y Comunicación entre procesos • Conceptos sobre Abrazo Mortal (Deadlocks) OBJETIVOS DEL APRENDIZAJE: Después de estudiar este módulo, el alumno deberá estar en condiciones de: • Explicar y reconocer los distintos algoritmos de sincronización y comunicación entre procesos. • Comprender los conceptos y características de la concurrencia de los procesos. • Explicar la situación de Deadlock y como evitarla. • Explicar la terminología específica empleada en éste módulo. 2

. Sincronización y comunicación entre procesos Ø SINCRONIZACIÓN entre Procesos: Ordenamiento de las operaciones en el tiempo debido a las condiciones de carrera (acceder a los diversos recursos asincrónicamente). Ø COMUNICACIÓN ENTRE PROCESOS (IPC): Intercambio de Datos. 3

Problemas concurrentes: Los Programas pueden ser clasificados en secuenciales y en concurrentes. § Un programa secuencial especifica una secuencia de instrucciones que se ejecutan sobre un procesador que definimos como proceso o tarea. § Un programa concurrente especifica dos o más procesos secuenciales que pueden ejecutar concurrentemente como tareas paralelas. § Un proceso secuencial se caracteriza por no ser dependiente de la velocidad de ejecución y de producir el mismo resultado para un mismo conjunto de datos de entrada. §Un proceso concurrente las actividades están superpuestas en el tiempo §La programación concurrente requiere de mecanismos 4 de sincronización y comunicación entre los procesos.

Grafos de precedencia. Un grafo de precedencia es un grafo sin ciclos donde cada nodo representa una única sentencia o un conjunto secuencial de instrucciones agrupadas. • Un arco que sale del nodo S 1 hacia S 2 indica que S 2 puede ser ejecutado sólo si S 1 ha completado su ejecución. 5

Condiciones de Concurrencia (Bernstein) Establecemos la siguiente notación: • Conjunto de Lectura: R (Si) = ( a 1, a 2, . . . , am) El conjunto de lectura de la sentencia Si es aquel formado por todas las variables que son referenciadas por la sentencia Si durante su ejecución sin sufrir cambios. • Conjunto de escritura: W (Si) = (b 1, b 2, . . . , bn) El conjunto de escritura de la sentencia Si es aquel formado por todas las variables cuyos valores son modificados durante la ejecución de Si. S 1 S 2 Ejemplo: S 1 a + b = c S 2 d * b = e S 4 S 3 f / c = g S 4 e - h = i Lectores Escritores 6

Condiciones de Concurrencia (Bernstein) Definición: Dos sentencias cualesquiera S i y Sk pueden ejecutarse concurrentemente produciendo el mismo resultado que si se ejecutaran secuencialmente sí sólo sí se cumplen las siguientes condiciones: 1. R (Si) W (Sk) = (ø) 2. W(Si) R (Sk) = (ø) 3. W(Si) W (Sk) = (ø) Si las tres condiciones producen conjunto vacío, podemos asegurar que no hay dependencia entre las sentencias. 7 Siempre se evalúan pares de sentencias por ejemplo Si y Sk.

Procesos concurrentes • Permiten la ejecución secuencial de varios thread o procesos • Permite sacar ventaja de : • Paralelismo de operaciones de CPU y E/S • Existencia de varios procesadores • Cooperación de un grupo de procesos concurrentes introduce nuevos problemas: • No determinismo en la operación. • Existencia de secciones criticas • Posibilidad de deadlock 8

Expresión fork / join • Un fork divide el flujo de control en dos threads, indcandose con una etiqueta donde comienza la ejecución del segundo thread. • Un join permite unir varios threads paralelos en uno solo. Ejemplos de fork / join: sent 1; sent 2; fork etiq; . . . join; . . . end; etiq: sent 1; sent 2; . . . sentn; quit; S 1; Cont = 3; Fork L 1; S 2 S 3 S 2; Fork L 2; S 4 S 5 Goto L 3; L 2: S 5; goto L 3; S 6 L 1: S 3; L 3 joint cont; S 6; 9

CCOBEGIN / COEND · Década 80 Hoare lo llamó parbegin y parend por paralel-begin/end. · Década 90 se designa concurent en lugar de paralel. F Todas las instrucciones insertadas entre cobegin y coend pueden ejecutarse concurrentemente. CCOBEGIN sent 1; sent 2; . . . sentn; CCOEND Cada senti puede ser un grupo de sentencias con esta construcción se están creando n procesos concurrentes c/u de los cuales debe ejecutar completamente antes que el proceso creador pueda continuar. La sent n+1 solo puede ejecutarse solo si Si = 1, . . . , n han terminado. 10

· CCOBEGIN / COEND Ejemplo: Programa para encontrar el máximo entre 4 números. fork max 1; fork max 2; join; cobegin m=max(m 1, m 2) m 1=max(a, b); return m; m 2=max(c, d); coend max 1: m=max(m 1, m 2); m 1=max(a, b); quit; return m; max 2: m 2=max(c, d); quit; 11

Relaciones entre procesos concurrentes y sus conflictos Procesos interactuantes (son procesos concurrentes. Su orden de ejecución afectan a los demás procesos) Un proceso es interactuante si puede afectar o ser afectado por otros procesos. 1. su estado es compartido con otros procesos. 2. el resultado de su ejecución no puede ser predicho ya que depende de la ejecución de otros procesos. Ejemplo: 12

Ejemplo: Independientes COBEGIN M 1 = MAX (A, B); M 2 = MAX (C, D); COEND M = MAX (M 1, M 2); Interactuantes J = 10; COBEGIN PRINT J; J = 1000; COEND El resultado del ejemplo de la derecha depende de las velocidades relativas de los dos procesos. El Kernel que multiplexa el procesador no controla con precisión las señales de interrupción. Como los procesos no ejecutan exactamente a la misma velocidad aparece una condición de concurso (race condition). 13

RACE CONDITION: Race Condition: Situación en la cual el resultado de la ejecución de 2 o más procesos interactuantes depende del orden de ejecución de los mismos. J = 10; Cobegin Print j; J = 1000; Coend ¿Cómo solucionar una condición de concurso? Hay que lograr mutua exclusión, es decir un mecanismo que permita que los procesos accedan en forma ordenada al recurso compartido. ¿Qué valor Imprime? 14

Problemas de la Concurrencia • Compartir recursos globales • Administración de la asignación de recursos. • Dificultad para detectar errores de programación. • Condiciones de concurso (Race conditions). 15

Funciones del Sistema Operativo • Seguimiento de los procesos activos • Asignación y desasignación de recursos – Tiempo de procesador – Memoria – Archivos – Dispositivos de Entrada/Salida • Protección de datos y recursos • El resultado del procesamiento debe ser independiente de la velocidad de ejecución de otros procesos concurrentes 16

Introducción al problema de la sección crítica • Los puntos de entrada de un recurso indican la cantidad de procesos que pueden utilizarlo simultáneamente al mismo. • Un recurso con un punto de entrada se lo denomina recurso crítico o no compartible. • Sección crítica de un proceso es la fase o etapa en la vida de ese proceso concurrente en la cual accede a un recurso crítico. • Las condiciones de concurso se presentan debido a la presencia de secciones críticas dentro de los procesos. 17

Condiciones para una solución al problema de la seccion crítica • Mutua Exclusión: Si un thread o un proceso esta en su sección crítica, entonces ningún otro puede estarlo. • Progresión: Ningún proceso intentando o estando dentro de la sección crítica puede impedir el progreso de un proceso que esta fuera de la sección crítica • Espera limitada: Existe tiempo finito desde que un proceso solicita entrar a la sección crítica hasta que lo consigue. Impide inanición o postergación indefinida. • Abandono (Tiempo limitado) : debe dejar a la SC en un tiempo finito. • Penalidad: Un Proceso no puede consumir tiempo de ejecución mientras espera por un recurso. • Privilegio: No debe haber ningún proceso privilegiado que monopolice la SC 18

Protocolo para usar la Sección crítica El protocolo se basa en las 6 condiciones para usar la SC. Este protocolo de sincronización se implementa de forma tal que cada proceso debe ejecutar el siguiente código para usar un recurso crítico. /* (SC) designa una serie de instrucciones que utilizan el recurso crítico y cumplen con el protocolo y éstas instrucciones se descomponen en tres etapas. */ Mutua exclusión (SC) { Protocolo de entrada. SC(); Sincronización usar. Recurso(); salida. SC(); } Las funciones entrada. SC() y salida. SC() se deben implementar de forma tal que cumplan el protocolo de sincronización. Estas dos funciones determinan el algoritmo de sincronización utilizado. En general se resuelven mediante un Hardware cableado o un mecanismo explicito de ejecución atómico (Master - Slave) que impide los tratamientos 19 de las interrupciones.

Primera Aproximación: con espera activa • Busy Waiting (Espera activa en el uso de CPU) – Un proceso está siempre verificando si puede acceder a su región crítica. • Por ejemplo: Usa la sentencia “while”. – Un proceso no puede hacer nada productivo hasta que obtiene permiso de acceder a su región crítica. 20

Algoritmos de sincronización con espera activa. • Espera activa o busy waiting significa que el proceso sigue ocupando la CPU mientras no puede entrar a su región crítica (el proceso no se bloquea). • El algoritmo queda realizando un spinlock chequeando el recurso hasta que éste es liberado. • El gran problema con estos algoritmos es que desperdician tiempo de CPU. 21

Soluciones a la Primera Aproximación (con espera activa) • Cada proceso tiene un turno en la región crítica • Si un proceso necesita la región crítica, cambia su estado y puede tener que esperar por su turno. • El algoritmo queda realizando un spinlock verificando el recurso hasta que éste es liberado. • El gran problema con estos algoritmos es que usan CPU para probar el estado de la RC y desperdician tiempo. · Se declara una variable pública booleana en que v = 0 indica recurso desocupado y v = 1 recurso ocupado · Se consulta a “v” para poder entrar. Si es cero 22 entra y lo coloca en “ 1” y cuando sale lo pone en

Solución #1 al problema de Dijsktra • Se usa una variable compartida (ocupada) que priorice el proceso que tiene derecho a acceder a la Sección Crítica entrada. RC() { do ; while(ocupada); ocupada = 1; } salida. RC() { ocupada = 0; } Se lo conoce como “Algoritmo de Variables de Cierre”. No Garantiza mutua Exclusión 23

Solución #2: Espera ocupada por turnos (Alternancia Estricta) • Asumimos la existencia de dos procesos 0 y 1. entrada. RC(int i) { while(turno != i); } salida. RC(int i) { turno = 1 - i; } • Asegura que haya sólo un proceso en la Región Critica. • Exige alternancia estricta. Si turno = 0 y P 1 está listo para entrar entonces debe esperar, aunque P 0 no esté en R C. • Usado en esquemas multiprocesadores para acceder a zonas de memoria compartida. 24

Solución #3 – Solución de Peterson Asumimos la existencia de dos procesos 0 y 1. Utiliza dos variables: • vector interesado[ ], donde cada proceso indica si está interesado en entrar. • variable turno igual que antes. entrada. RC(int i) salida. RC(int i) { { interesado[i] = 1; interesado[i] = 0; turno = i; } while(turno==i && interesado[1 -i] == 1); } 25

Algoritmo de Dekker • Proceso manifiestan intención de ingresar antes de verificar si procesos se excluyen mutuamente. En caso de colisión se arrepiente solo en proceso que tiene el turno. • Procesos comparten un arreglo que indican si un proceso tiene intención o esta en su SC y variable turno. Inicialmente : flag[i] = FALSE; /*para todo proceso i*/ turno = 0; Condición: Proceso i ingresa a la SC solamente si: flag[i] == TRUE && turno == i; Procesoi () { int j = i – 1; do { hacer algo; flag[i] = TRUE; while (flag[j]) { if(turno == i - 1) { flag[i] = FALSE; while (turno == i-1) skip; flag[i] = TRUE; } } 26

Algoritmo de Dekker (Cont) | sección crítica | turno = j; Flag[i] = FALSE; continuar con el programa; } while (forever); } • El algoritmo de Dekker es fácilmente ampliable a n procesos. • Resuelve el problema mediante una tabla unidimensional de dos elementos lógicos (switches). • Resuelve el problema de la mutua exclusión para 2 procesos con un programa complejo, difícil de seguir y de demostrar. • No funciona en arquitecturas con multiprocesadores. 27

Semáforos (Disjktra) • Herramienta genérica de sincronización (ordenamiento de las operaciones en el tiempo) de procesos. • Es una función dentro del Kernel. • Un semáforo S es una variable entera e(s) llamada valor del semáforo con las siguientes propiedades: 1. La variable puede tomar cualquier valor (entero positivo, negativo o nulo) en e(s) (valor del semáforo). 2. Se crea mediante un system call o una declaración, donde se especifica el valor inicial del semáforo que debe ser un entero no negativo. 3. Sólo es accesible mediante dos operadores primitivos atómicos down() y up() (Tanenbaum), Wait() y Signal() Silberschatz y Stallings. P(s) y V(s) Disjktra NOTA: Usaremos P(s) y V(s) en honor a su creador. 28

Semáforos – propuesto por Disjktra Operaciones de un semáforo • P: Ocupa la variable (decremento); se conoce también coma wait. • V: Libera la variable (incremento); se conoce también como signal. • P y V se realizan atómicamente de la siguiente manera: void P (semaforo s) { V (semaforo s) void V (semaforo s) { while (s ≤ 0) s++; /* nada */; } s--; } 29

Mutua Exclusión: soporte de Hardware • Inhabilitación de Interrupciones – Un proceso ejecuta hasta que invoca un servicio del S. O. o es interrumpido – Inhabilitar interrupciones garantiza la mutua exclusión – El procesador es limitado en su capacidad de solapar procesos – Multiprocesamiento • inhabilitar interrupciones en un sólo procesador no garantiza la mutua exclusión. 30

Mutua Exclusión: soporte de Hardware • Instrucciones de Máquina Especiales: – Realizadas en un sólo ciclo de instrucción. – No sujetas a interferencia de otras instrucciones. – Lectura y prueba. – Lectura y escritura. Ejemplo TAS o TSL (Test and Set Lock) o intercambio (swap) 31

Exclusión mutua: soluciones por hardware – Instrucciones especiales de la máquina: Instrucción Test and Set • Es una instrucción de máquina que se especifica como la siguiente función booleana y atómica: boolean testandset (int i) { if (i == 0) { i = 1; return true; } else { return false; } } Ventajas del uso de instrucciones especiales de la máquina: • Es aplicable a cualquier número de procesos. • Es simple y fácil de verificar. 32 • Puede usarse para disponer de varias secciones criticas.

Mutua Exclusión: soporte de Hardware • Instrucción Exchange void exchange(int register, int memory) { int temp; temp = memory; memory = register; register = temp; } 33

Mutua Exclusión: Instrucciones de Máquina • Ventajas – Aplicable a cualquier número de procesos con un procesador o múltiples procesadores compartiendo la memoria central. – Es simple y fácil de verificar. – Puede ser usado para soportar varias secciones críticas. • Desventajas – Busy-waiting consume tiempo de procesador. – Es posible que haya Starvation cuando un proceso libera la SC y más de un proceso espera. – Pueden generar Deadlock § Si un proceso de baja prioridad tiene la SC y un proceso de mayor prioridad la necesita, el proceso de mayor prioridad obtendrá el procesador para esperar por la SC. 34

Segunda Aproximación: Sin espera activa • Cada proceso puede examinar el estado de los demás pero no alterarlo. • Cuando un proceso desea entrar a su sección crítica, verifica primero a los otros procesos. • Si ningún otro proceso está en la sección crítica, cambia su estado al de la sección crítica. • Este método garantiza la mutua exclusión. • Si un proceso está en la sección crítica cuando su estado está marcado, el proceso es bloqueado y puesto en una cola de espera hasta que el otro proceso libera la sección crítica y lo saca de la cola. 35

Algoritmos sin espera activa Para evitar el problema de la espera activa se diseñan algoritmos que además del protocolo de sincronización cumplan con las siguientes reglas: 1. Si un proceso no puede entrar en la RC, pasa a una cola de espera asociada al semáforo. 2. Si un proceso sale de su RC, activa a uno de los procesos de la cola de espera asociada al semáforo, si es que no está vacía. 3. La cola está vacía inicialmente. Dos nuevas funciones: 1. sleep (): añade el proceso actual a la cola y lo pone en estado inactivo. 2. wakeup(): Activa un proceso de la Q; lo pasa de detenido a listo. La elección de que proceso a activar no es responsabilidad de la función sino del Kernel. 36

Solución con Semáforos sin espera activa . En lugar de una variable entera simple, utilizamos una estructura con dos elementos: La variable que indica el valor del semáforo y una cola de procesos asociada al semáforo. V(s) P(semaforo. s) { Ttypedef struct { s. valor++; s. valor--; iint valor; if (s. valor < if (s. valor ≤ 0) { cola Q; 0) p = dequeue(s. Q); } { wakeup(p); ssemaforo; enqueue(s. Q } ); } sleep(); } } Las Funciones enqueue() y dequeue() también son provistas por el S. O. al igual que sleep() y wakeup(). 37

Semáforo sin espera activa (Propiedades): 1. Valor inicial positivo o 0, puede hacerse negativo luego de un número determinado de P(). 2. En monoprocesador, para asegurar ejecución atómica, el S. O. inhibe interrupciones antes del P(). En un esquema multiprocesador esto no se puede hacer ¿porqué? (por las características de las interrupciones en multiprocesamiento). 3. Sea np(s) cantidad de instrucciones P()ejecutadas en el semáforo; nv(s) cantidad de instrucciones V()ejecutadas; ei(s) el 38

Semáforo sin espera activa (Propiedades): 4. Si e(s) < 0 entonces e(s) es el número de procesos que están esperando para usar el recurso. 5. Si e(s) 0 luego e(s) cantidad de procesos que pueden franquear el semáforo sin ser bloqueados. 6. Sea n. Q(s) la cant. de procesos que han ejecutado la primitiva P(s) (es decir que no se han bloqueado por ella o se han bloqueado primero y después desbloqueado). En todo momento tendremos: 39

Semáforo sin espera activa (Propiedades): EEl valor del semáforo indica la cantidad de puntos de entrada que tiene el recurso. Un semáforo con valor 1 indica un recurso crítico, por lo tanto se lo llama semáforo mutex o de mutua exclusión y si su valor es cero es un semáforo binario (sirve para contar mensajes, eventos, etc). 40

Problema de los Filósofos Comensales (Disjktra) 41

Regiones críticas Condicionales Construcción del Lenguaje de alto nivel (Compilador) Se declara una variable: var v: shared T; La variable v sólo puede ser accedida dentro de la sentencia region: region v do S; Mientras S se ejecuta, nadie puede acceder a v. Región crítica condicional: extensión de la anterior region v when E do S; Si además de estar v disponible, se cumple E (una condición arbitraria generalmente booleana) entonces entra a la región y ejecuta S. 42

Monitores (C. A. R. Hoare) • El Monitor es un módulo software. • Primitiva del alto nivel implementado por compilador • Características principales – Las variables de datos locales son accedidas sólo por el monitor – Un proceso entra al monitor invocando uno de sus procedimientos – Sólo un proceso puede ejecutar en el monitor al mismo tiempo 43

Monitores • Las características básicas de un monitor son las siguientes: – Las variable de datos locales están sólo accesibles para los procedimientos del monitor y no para procedimientos externos. – Un proceso entra en el monitor invocando a uno de sus procedimientos. – Solo un proceso puede estar ejecutando en el monitor en un instante dado; cualquier otro proceso quedara suspendido mientras espera a que el monitor este disponible. Operaciones de sincronización • Signal: reanuda exactamente a un proceso que se encuentre bloqueado en la variable de condición. (si no existe tal proceso no tiene efecto). • Wait: bloquea en la variable al proceso que ejecuta esta operación. 44

Modelo de Monitor Cola de Entrada de Procesos Área de Espera del Monitor Datos Locales Condición c 1 cwait(c 1) Variables Condicionales Procedimiento A MONITOR Condición cn cwait(cn) Procedimiento N Cola de urgentes csignal Código de Inicialización 45 Salida

Transmisión de mensajes La comunicación entre dos procesos puede ser realizada de dos maneras: 1. Comunicación a través de un área común de memoria o 2. Comunicación mediante el intercambio de mensajes. Dos primitivas: Origen Destino Longitud del mensaje Información de control Tipo de mensaje Contenido del mensaje Cabecera Cuerpo 46 Formato típico de mensaje

Comunicación directa send(P, mensaje): envía mensaje a P receive(Q, mensaje): recibe mensaje de Q Propiedades: 1. Se establece un vínculo automáticamente entre los procesos. Sólo deben conocerse mutuamente. 2. El vínculo se establece con 2 procesos exactamente. 3. El vínculo es bidireccional. p() c() { { while(1) { { x = producir(); recibir(c, &x); send(c, x); consumir(x); } } desventajas: 1. poca modularidad (rígido). 47 2. Si se cambia la id de un proceso, puede ser necesario revisar el código de los otros.

Comunicación indirecta 1. Los mensajes van y vienen a buzones (mailboxes) o puertos. 2. Cada buzón tiene su propia identificación luego los procesos se comunican compartiendo una determinada cantidad de buzones. 3. Para comunicarse deben tener un buzón compartido. send(A, msj): envía msj a buzón A. receive(A, &msj): busca msj de buzón A. 4. Propiedades: a) Vínculo sólo se establece si ambos procesos comparten un mailbox. b) Link puede ser asociado con más de 2 procesos. c) Entre cada par de procesos puede haber varios links distintos cada uno correspondiente a un mailbox. d) Un link puede ser uni o bidireccional. 48

Direccionamiento indirecto • Direccionamiento indirecto –Los mensajes son enviados a una estructura de datos compartida consistente en colas o buzones –Las colas son llamadas “casillas de correo” –Un proceso envía el mensaje a la casilla y el otro proceso toma el mensaje de la casilla 49

Proceso Emisor Proceso Receptor Proceso Q 1 Proceso P 1 Mailbox (Buzón) A Proceso Pn Proceso Qn Proceso P 1 Port (Puerto) B Proceso Pn Proceso Q 1 50

Problema de los Lectores/Escritores • Cualquier número de lectores pueden leer el archivo simultáneamente • Sólo un escritor a la vez puede escribir en el archivo • Si un escritor está escribiendo en el archivo, ningún lector puede leerlo 51

Paso de Mensajes • Forzar la mutua exclusión • Intercambiar información send(destination, message, #MSG) receive(source, message, #MSG) 52

Comunicación Sincrónica - rendezvous • El emisor y el receptor pueden o no estar bloqueando (esperando un mensaje) • Send bloqueante, receive bloqueante – Ambos emisor y receptor son bloqueados hasta que el mensaje se recibe – Esto es llamado Reunión (rendezvous) V(T) P(T) P(R) ) V(R) Send(msg) Receive(msg) 53

Comunicación Sincrónica – rendezvous extendido • Es una extensión del mecanismo anterior. • Emisor bloqueado hasta recibir respuesta del receptor. • Receptor envía respuesta después de ejecutar en cuerpo de comandos que operan sobre el mensaje. • La respuesta pueden poseer parámetros que contengan resultados de los cálculos efectuados por el Receptor. V(T); P(T); Send(msg); Receive(msg); P(R) ) if ok then V(R); 54

Comunicación Sincrónica – rendezvous asimétrico • • Es una variante del rendezvous extendido. Emisor (cliente) nombra al receptor (servidor). Receive se reemplaza por el comando accept. Ambos quedan bloqueados hasta se complete la ejecución de todo el cuerpo del accept. • El accept no nombra al proceso emisor pues la comunicación ya fue establecida a priori. T(); R() { { Send(R, msg); accept send(msg); } y = msg; } 55

Comunicación Sincrónica – rendezvous asimétrico • Direccionamiento directo – La primitiva send incluye un identificador específico del proceso destino – La primitiva receive puede saber de antemano qué proceso espera un mensaje – La primitiva receive puede usar el parámetro source para retornar un valor cuando la operación receive ha sido realizada 56

Comunicación Asincrónica • El emisor y el receptor no están bloqueados. • Send no bloqueante, receive no bloqueante. Cada uno sigue ejecutando aunque no lleguen mensajes. 57

Comunicación Semi-sincrónica • Send no bloqueante, receive bloqueante – El emisor continúa enviando mensajes lo más rápido posible – El receptor es bloqueado hasta que el mensaje llega • Es Riesgoso por la acumulación de gran cantidad de mensajes en colas. 58

Paso de Mensajes · -Medio de comunicación entre procesos que ofrece el S. O. · -Se debe abrir una conexión y conocer el nombre del comunicador (proceso en la misma CPU o no) · -En red cada computador tiene el nombre del anfitrión y cada proceso tiene nombre de proceso. · -La fuente de la comunicación conocida como cliente y el demonio (daemons) que recibe servidor, intercambian mensajes mediante llamadas al sistema. · -Para intercambiar pequeñas cantidades de datos. · -Evita conflictos. · -Más fácil de usar para comunicación entre computadoras. MEMORIA COMPARTIDA · -Utiliza llamadas para correspondencia de memoria con el propósito de obtener acceso a los registros de memoria que pertenecen a otros procesos. · -Evita que un proceso tenga acceso a la memoria de otro. Para compartir la memoria se requiere que dos o más procesos estén de acuerdo en eliminar esta restricción y así intercambiar información leyendo y escribiendo datos en éstas áreas compartidas. · -Forma de datos y ubicación están determinadas por esos procesos y no por el S. O. Los cuales también se encargan que no se escriba en posiciones iguales de memoria a la vez. · -Máxima velocidad y conveniencia en la comunicación (puede efectuarse a la velocidad de la memoria) · -Problemas en el área de protección y sincronización. 59

Modelo productor- consumidor (bounded buffer) Usado para describir dos procesos ejecutando en forma concurrente: 1. Productor: Genera un conjunto de datos necesarios para la ejecución de otro proceso. 2. Consumidor: Toma los datos generados por el productor y 60 los utiliza para su procesamiento. Ejemplos: ls | more

Modelo productor-consumidor (bounded buffer) Productor: Genera elementos y los ingresa en el buffer. Buffer: Zona de memoria utilizada para amortiguar las diferencias de velocidad entre dos procesos. Almacena temporalmente los elementos generados por P. Consumidor: Retira los elementos del buffer y los consume. Restricciones: 1. El productor no puede sobrepasar, el envío en uno, la capacidad del buffer 2. El consumidor no puede consumir más rápido de lo que se produce. Se utiliza el siguiente protocolo de sincronización: 1. Si el productor quiere poner un elemento en un buffer lleno entonces es demorado hasta que el consumidor saque uno. 2. Si el consumidor intenta tomar mensajes de buffer vacío entonces es demorado hasta que el productor ingrese uno. 61

Condiciones: La secuencia de mensajes enviados y recibidos son dos arreglos infinitos R (mensajes recibidos) y S (mensajes enviados) con índices r y s. Deben cumplir con las siguientes condiciones: • El número de mensajes recibido no puede exceder el No de mensajes enviados: 0 r s MAX • El No de Mensajes enviados, pero aún no recibidos, no pueden exceder la capacidad máxima del Buffer (MAX): 0 s - r MAX • Los mensajes deben recibirse exactamente en el orden en que son enviados: for i: 1 i s, S[i] = R[i] Se puede plantear el siguiente invariante de comunicaciones: 0 r s r + MAX (Invariante de comunicación) for i: 1 i s, S[i] = R[i • El consumidor deberá sacar todo los mensajes de una sola 62 vez.

Problema del Productor/Consumidor • Uno o más productores generan datos y los ubican en un buffer • Sólo un consumidor retira ítems del buffer de a uno por vez. • Sólo un productor o un consumidor pueden acceder al buffer al mismo tiempo (RC). 63

Productor Consumidor consumidor: productor: while (true) { /* produce item v */ while (in <= out); /* no hacer nada */ b[in] = v; w = b[out]; in++; out++; /* consume } item w */ } 64

Productor con Buffer Circular productor: while (true) { /* produce item v */ while ((in + 1) % n == out) /* no hacer nada */; b[in] = v; in = (in + 1) % n } Consumidor con Buffer Circular consumidor: while (true) { while (in == out) /* no hacer nada */; w = b[out]; out = (out + 1) % n; /* consume item w */ } 65

Modelo de Productor y Consumidor con un Buffer Circular 66 Baffer circular finito para el problema de Productor/Consumidor

Buffer Infinito b[1] b[2] b[3] b[4] b[5]. . out in Nota: el área sombreada indica la porción del buffer ocupada Buffer infinito para el problema de Productor/ Consumidor 67

Algunos algoritmos para el modelo productor- consumidor Los algoritmos modelan el comportamiento del productor (p) y del consumidor (c) de forma tal que se cumpla el protocolo de sincronización. A. sleep() wakeup() y ingresar() sacar() sleep(): Llamada al sistema que bloquea al proceso solicitante. wakeup(): Llamada al sistema que tiene como parámetro el PID del proceso a desbloquear. ingresar() sacar(): Llamadas al sistema para el uso de una cola. Se usa una variable cont que indica la cantidad de lugares ocupados que tiene el buffer. p() c() { { while (1) { { x = producir(); if (cont == 0) if (cont == N) sleep(); x = sacar(); cont++; cont--; ingresar(x); if (cont == N - 1) if (cont == 1) wakeup(p); wakeup(c); consumir(x); } } Presenta al menos una condición de concurso. El algoritmo falla. } } Condición de concurso: Buffer vacío y consumidor acaba de leer cont para verificar si es 0. Ahí, lo interrumpen y pasa al productor; éste ingresa un elemento en el buffer por lo que razonando que cont era 0, despierta al consumidor, pero esa señal se pierde por lo que el consumidor probará el viejo valor de cont y se bloqueará. 68

Contadores de eventos (Reed y Kanodia) Un contador de eventos es una variable especial que tiene 3 operaciones: 1. read(e): Devuelve el valor de e. 2. advance(e): Incrementa atómicamente el valor de e en 1. 3. await(e, v): Espera hasta que e v. p() { int prod; while (1) { x = producir(); prod++; await(N, prod-sacados); ingresar(x); advance(ing); } } c() { int sec; while (1) { sec++; await(ing, sec); x = sacar(); advance(sacados); consumir(x); } } ing: Cuenta el número acumulativo de elementos que el productor colocó en el buffer. sacados: Cuenta el número acumulativo de elementos que el consumidor retiró del buffer. 69

Semáforos Usa tres semáforos: semaforo mutex = 1, vacío = Max, lleno = 0; prod() { while (1) { x = producir(); P(vacío); P(mutex); ingresar(x); V(mutex); V(lleno); } } cons() { while(1) { P(lleno); P(mutex); x = sacar() V(mutex); V(vacío); consumir(x); } } 70

Problema del Peluquero Barberos Cajero Entrada Área de Espera Salida Sofá 71

Concurrencia: Deadlock y Starvation 72

Deadlock: definición • “Un conjunto de procesos esta en estado de deadlock cuando cada uno de los procesos está esperando por un evento que puede ser causado sólo por otro proceso del conjunto” • Ejemplo de Deadlock R 1 P 2 P 3 Tres procesos usan tres recursos compartidos del mismo tipo. 73

Deadlock: concepto • Un proceso esta en Deadlock (Abrazo mortal) si espera por un evento que nunca ocurrirá. • Un proceso que se encuentra en este estado y que tiene recursos asignados que son demandados por otros procesos afecta al desempeño y funcionamiento del sistema. • Esto produce un efecto indeseado. • Muchos de los S. O. Actuales no provee soluciones para resolver este tipo de problemas. • El sistema consiste de un número finito de recursos entre un grupo de procesos que compiten por estos. • Solicitud de recursos • Los recursos pueden ser varios del mismo tipo • Los procesos para usar un recurso debe pedirlos del siguiente modo: • Solicitar el recurso – <Usar el recurso> – Liberar el recurso • Solicitar y liberar un recurso son llamadas al sistema. 74

Deadlock Estado en el que dos o más procesos esperan por condiciones que no se dan y que deben producirse por procesos de ese conjunto. que nunca se van a cumplir. • El problema es de naturaleza lógica. 75

Grafo de Asignación de Recursos 76

Recursos Reusables • Usados por un proceso a la vez • Los procesos obtienen recursos que luego liberan para ser reusados por otros procesos • Los procesadores, canales de E/S, memoria central y secundaria, archivos, bases de datos, y semáforos • Existe Deadlock si cada proceso retiene un recurso y solicita otros. 77

Recursos Consumibles • Son creados (producidos) y destruidos (consumidos) por un proceso • Las interrupciones, señales, mensajes, e información in buffers de E/S • Puede haber Deadlock si un mensaje receive está bloqueando a otros • Puede ser necesaria una rara combinación de eventos para que exista Deadlock 78

Condiciones para que haya Deadlock (Coffman) • Mutua Exclusión – sólo un proceso puede usar un recurso a la vez • Retener y esperar (Hold-and-wait) – un proceso solicita todos los recursos requeridos al mismo tiempo • No Expropiación (No Preemptive) – Si a un proceso que retiene ciertos recursos se le niega una solicitud, ese proceso debe liberar sus recursos originales – Si un proceso solicita un recurso que está siendo retenido por otro proceso, el S. O. puede instar al segundo proceso a que libere sus recursos • Espera circular – Prevenida definiendo un orden lineal de los tipos de 79 recurso

Condiciones para que haya Deadlock: Espera circular ido d e P Proceso P 1 r o p Recurso Retenido por P 1 A Ret enid o po r P 1 Ret enid o po 2 P r po r P 2 Proceso P 2 Recurso B ido d e P 80

Evitando Deadlocks • Se decide dinámicamente si la actual solicitud de asignación de recursos puede llevar a una situación de deadlock • Requiere el conocimiento de las solicitudes futuras de los procesos • Esto es costoso. · El Estado del Sistema: es la asignación actual de recursos a procesos, definido por el número de recursos disponibles, número de recursos asignados y el máximo pedido de cada proceso. • Un estado es seguro si existe un orden tal en el que los procesos pueden llevarse a cabo por completo, sin resultar en Deadlock. 81

Estrategias para tratar deadlocks Ignorarlo • Esta estrategia se utiliza cuando la frecuencia en que ocurren es baja. • Hay que evaluar el riesgo de una situación de Abrazo Mortal. • Analizar si el costo de ignorarlo es menor al costo que implicaría prevenirlo o detectarlo y recuperarlo. • Unix, Linux. NT Windows son S. O. que adoptan esta estrategia. • Tanenbaum propone como algoritmo el llamado “del avestruz” 82

Estrategias para tratar deadlocks • Prevención: • Esta estrategia resuelve el problema limitando el uso de los recursos e imponiendo restricciones a los procesos. • Siendo las cuatro condiciones necesarias para que ocurra un Deadlock basta con asegurarnos que una de ellas no ocurrirá. • Las restricciones y limitaciones se imponen con el fin de prevenir que una de las condiciones no ocurra. 83

Prevención que una de las condiciones no se dé Mutua Exclusión: Aquellos recursos que no son compartidos, no causan problemas, ya que los mismos pueden ser utilizados por cualquier proceso en cualquier momento. Código Reentrante no se modifica cuando se usa. Se comparte su uso por varios procesos a la vez. Código Reusable puede modificarse durante el uso pero vuelve a su estado original (inicial) cada vez que se lo utiliza. Solo un proceso por vez. Control y espera (Hold & Wait): Para solucionar este problema, se trata de garantizar que cuando un proceso tenga un recurso asignado no pueda solicitar otro. Hay dos caminos para lograrlo: 1 - Los procesos solicitan todos los recursos en el momento previo a comenzar la ejecución, de no poder ser entregados el proceso queda bloqueado (caso COBOL). 2 - Un proceso primero debe liberar aquellos recursos que posee y luego recién podrá solicitar otros, es decir solo está en condiciones de solicitar un recurso cuando no tiene ninguno asignado. 84

Prevención que una de las condiciones no se dé • Recursos no expropiable (No Preemption): Para ésta condición también existen dos métodos: 1. Si un proceso solicita un recurso que no está disponible, éste debe devolver todos aquellos recursos que tenía previamente asignados. 2. Si un proceso pide un recurso que tiene otro proceso, el S. O. puede obligar a liberar los recursos al otro proceso. • Espera circular: Consiste en imponer un orden lineal de ejecución que evite las esperas circulares (se ejecuta un algoritmo que analiza si los procesos concurrentes pueden terminar). Este problema puede ser resuelto de la siguiente manera: • Estableciendo un orden lineal de los recursos 85

Dos Estrategias para evitar Deadlocks • No comenzar la ejecución un proceso si sus demandas pueden conducir a un deadlock • No asignar nuevos recursos a un proceso si dicha asignación puede conducir a un deadlock 86

• • Evitar Deadlocks (AVOIDANCE) La cantidad máxima de solicitudes de recursos debe ser determinada por anticipado. El proceso bajo consideración debe ser independiente; no debe haber necesidad de sincronización. Debe haber un número fijo de recursos a asignar Ningún proceso puede terminar reteniendo recursos 87

Negación de Asignación de Recursos • Conocido como el algoritmo del banquero • El estado del sistema es la asignación actual de recursos a procesos • Un estado seguro es cuando existe por lo menos una secuencia que no resulta en deadlock • Un estado inseguro es cuando no existe un estado seguro. • Se tiene un vector de recursos disponibles, una matriz de solicitudes y una matriz de asignados. |Disponibles| - |Solicitudes| = |Asignados| 88

Algoritmo del Banquero • Un banquero dispone de dinero suficiente para sastifacer a sus clientes • Cuando un proceso entra al sistema debe declarar sus necesidades máximas para cada tipo de recurso (no puede exceder el número total de recursos disponibles). • Cuando un proceso solicita un recurso el sistema determina si tal asignación deja al sistema en un estado seguro. ØSi es el caso seguro lo asigna. ØEn otro caso, el proceso debe esperar hasta que otro proceso libera suficientes recursos y se garantice que el sistema permanezca en estado segura. 89

Ejemplo de Estado seguro: ASIGNADOS SOLICITUDES DISPONIBLES A B C 0 0 0 2 0 2 A B C P 0 0 1 0 P 1 2 0 0 P 2 3 0 0 0 P 3 2 1 1 1 0 0 P 4 0 0 2 Ejecuta la siguiente secuencia: P 2; P 0; P 3; P 4 y P 1 (Todos terminan) Ejemplo de Estado inseguro: ASIGNADOS SOLICITUDES DISPONIBLES A B C 0 0 0 A 0 2 A B C P 0 0 1 0 P 1 2 0 0 P 2 3 0 0 1 P 3 2 1 1 1 0 0 P 4 0 0 2 B 0 C 0 Ejecuta solamente P 0. (Todos los demás quedan en Deadlock: 90 P 2; P 3; P 4 y P 1 )

Observaciones y detección de deadlock • Un estado no seguro no necesariamente puede llevar al sistema a un estado de deadlock. • Evitación de deadlock puede significar que los procesos esperen aún cuando el recurso solicitado este libre. • El algoritmo del banquero requiere que: Ø Exista un número fijo de recursos Ø El número de procesos sea conocido. Ø Solicitudes sean concedidas en tiempo finito Ø Los procesos deben definir a priori sus necesidades máximas. Detección de deadlock § Mediante un algoritmo se verifica la existencia o no de un estado de deadlock § Se permite la existencia de las tres primeras condiciones necesarias y se detecta la existencia de una espera circular. v El sistema operativo puede chequear periódicamente la existencia de 91 un deadlock

Estrategias a seguir una vez detectado el Deadlock • Terminar todos los procesos en bloqueados. • Hacer Back up de cada proceso bloqueado a un punto de verificación (chek point) definido previamente y reiniciar todos los procesos mediante rolback al punto anterior. • Terminar sucesivamente los procesos bloqueados hasta que no haya deadlock. • Expropiar recursos sucesivamente hasta que no haya deadlock 92

Criterio de Selección de Procesos “víctimas” en Deadlock • Menor cantidad de tiempo de procesador consumido hasta el momento • Menor cantidad de líneas de salida producidas hasta el momento • Mayor tiempo estimado restante • Menor cantidad de recursos asignados hasta el momento • Menor prioridad 93

Consideraciones para eliminar un proceso Una Técnica: Asignar un costo fijo (Ci) a la remoción de un recurso ri de una tarea que es abortada. El costo de liberar los recursos de una tarea ti en deadlock será: Se han desarrollado algoritmos, que mediante eficientes búsquedas en árboles, encuentran soluciones de costo mínimos. 94

Mecanismos de Concurrencia en UNIX • • • Tuberías (Pipes) Mensajes Memoria compartida Semáforos Señales 95

Primitivas de Sincronización de Threads en Solaris • Bloqueos de Mutua Exclusión (mutex) • Semáforos • Bloqueos de lectores múltiples, escritores simples (lectores/escritor) • Variables de condición 96

Estructuras de datos de Sincronización en SOLARIS 97

Estructuras de datos de Sincronización en SOLARIS 98

Mecanismos de Concurrencia en Windows 2000 • • • Proceso Thread Archivo Entrada por consola Notificación de cambio de archivo Mutex Semáforo Evento Reloj retrasable 99

Fin del Módulo 4. 100