Sistemas Operativos Tema 3 Comunicacin y sincronizacin de

Sistemas Operativos Tema 3 Comunicación y sincronización de procesos

Contenido • Introducción. • Tipos de procesos concurrentes. • Problemas clásicos de comunicación y sincronización. – – Sección crítica. Productor-consumidor. Lectores-escritores. Cliente-servidor. • Mecanismos de comunicación y sincronización. – – – Archivos. Tuberías. Llamadas al sistema para la gestión de tuberías. Semáforos. Llamadas al sistema para la gestión de semáforos. • Interbloqueos. Sistemas operativos: una visión aplicada de Miguel, F. Pérez Sistemas Distribuidos © J. Carretero, F. García, P.

Procesos concurrentes • Modelos – Multiprogramación en un único procesador: Se planifican los procesos en estado de listo. – Multiprocesador: Múltiples procesadores que comparten la memoria principal. Distintos procesos pueden aparecer a la vez en estado de procesamiento. – Multicomputador (proceso distribuido): La memoria se encuentra distribuida entre las diferentes máquinas. Cada uno de los ordenadores se denomina nodo. Se produce una interconexión a través de la red. • En general, la concurrencia será aparente siempre que el número de procesos sea mayor que el número de procesadores y real si hay un proceso por procesador. Sistemas operativos: una visión aplicada de Miguel, F. Pérez Sistemas Distribuidos © J. Carretero, F. García, P.

Procesos concurrentes • Razones – Facilita la programación de aplicaciones al permitir que un conjunto de proceso cooperen en un objetivo común. – Acelerar los cálculos. Si se quiere que una tarea se ejecute con mayor rapidez, lo que se puede hacer es dividirla en procesos, cada uno de los cuales se ejecutan en paralelo. La velocidad sólo aumenta con multiprocesadores o multicomputadoras. – Modularidad. Permite el uso interactivo a múltiples usuarios que trabajan de forma simultanea. – Aprovechamiento de recursos. Se disminuye el número de procesos nulos en el procesador. Sistemas operativos: una visión aplicada de Miguel, F. Pérez Sistemas Distribuidos © J. Carretero, F. García, P.

Sistema multiprogramado con un una CPU Sistemas operativos: una visión aplicada de Miguel, F. Pérez Sistemas Distribuidos © J. Carretero, F. García, P.

Ejecución en un sistema multiprocesador Sistemas operativos: una visión aplicada de Miguel, F. Pérez Sistemas Distribuidos © J. Carretero, F. García, P.

Contenido • Introducción. • Tipos de procesos concurrentes. • Problemas clásicos de comunicación y sincronización. – – Sección crítica. Productor-consumidor. Lectores-escritores. Cliente-servidor. • Mecanismos de comunicación y sincronización. – – – Archivos. Tuberías. Llamadas al sistema para la gestión de tuberías. Semáforos. Llamadas al sistema para la gestión de semáforos. • Interbloqueos. Sistemas operativos: una visión aplicada de Miguel, F. Pérez Sistemas Distribuidos © J. Carretero, F. García, P.

Tipos de procesos concurrentes • Independientes: Es aquel que ejecuta sin requerir la ayuda o la cooperación de otros procesos. Ej. mandatos en la shell. • Cooperantes: Se diseñan para trabajar conjuntamente en alguna actividad. Se comunican e interactuan entre si. • En ambos casos se pueden producirse interacciones debido a: – Los procesos comparten o compiten por el acceso a los recursos físicos o lógicos. Ej. acceso a disco por dos procesos que implica una gestión del SO. Dos procesos que modifican los registros de una base de datos. – Interacción motivada porque se comunican y sincronizan entre sí para alcanzar un objetivo común. Ej. Compilador y Ensamblador se comunican y sincronizan para producir código máquina. Sistemas operativos: una visión aplicada de Miguel, F. Pérez Sistemas Distribuidos © J. Carretero, F. García, P.

Contenido • Introducción. • Tipos de procesos concurrentes. • Problemas clásicos de comunicación y sincronización. – – Sección crítica. Productor-consumidor. Lectores-escritores. Cliente-servidor. • Mecanismos de comunicación y sincronización. – – – Archivos. Tuberías. Llamadas al sistema para la gestión de tuberías. Semáforos. Llamadas al sistema para la gestión de semáforos. • Interbloqueos. Sistemas operativos: una visión aplicada de Miguel, F. Pérez Sistemas Distribuidos © J. Carretero, F. García, P.

Problema de la sección crítica • Problema común tanto en procesos independientes como cooperantes. • Sea un sistema compuesto por n procesos donde cada uno tiene un fragmento de código: sección crítica. • Dentro de la sección crítica se pueden estar accediendo y modificando variables comunes, registros de un archivo, etc. • Sólo uno de los procesos en cada instante puede ejecutar en la sección crítica – Cuando un proceso está ejecutando en la sección crítica, ningún otro puede hacerlo. • Ejemplo: – Se asigna un PID a dos procesos en un sistema multiprocesador. – Para asignar un nuevo PID, el SO realiza las siguientes acciones: • Leer el último PID asignado. • Incrementar el valor del último PID. El nuevo valor será el PID a asignar al proceso. • Almacenar el nuevo PID en el registro o variable utilizado para tal efecto. Sistemas operativos: una visión aplicada de Miguel, F. Pérez Sistemas Distribuidos © J. Carretero, F. García, P.

Ejemplo 1 Sistemas operativos: una visión aplicada de Miguel, F. Pérez Sistemas Distribuidos © J. Carretero, F. García, P.

Sección crítica • Cuando el SO ejecuta las operaciones de la figura anterior en dos procesadores de forma simultánea si ningún tipo de control, se pueden producir errores y asignar el mismo PID al dos procesos distintos. • Las operaciones descritas anteriormente deben realizarse de forma atómica, es decir, de forma completa e indivisible. Así, si un proceso que empieza a ejecutar código de la sección crítica, entonces ningún otro proceso podrá ejecutar dicho código mientras el primero no haya acabado su sección. • Ejemplo: – Se quiere calcular la suma de los n primeros números naturales de forma paralela utilizando múltiples procesos ligeros, cada uno de los cuales se va ha encargar de la suma de un subconjunto de todos los números. Sistemas operativos: una visión aplicada de Miguel, F. Pérez Sistemas Distribuidos © J. Carretero, F. García, P.

Ejemplo 2 Sistemas operativos: una visión aplicada de Miguel, F. Pérez Sistemas Distribuidos © J. Carretero, F. García, P.

Ejemplo 2 • Calcula la suma de los N primeros números utilizando procesos ligeros. int suma_total = 0; void suma_parcial(int ni, int nf) { int j = 0; int suma = 0; for (j = ni; j <= nf; j++) suma = suma + j; suma_total = suma_total + suma; pthread_exit(0); } • Si varios procesos ejecutan concurrentemente este código se puede obtener un resultado incorrecto. • Solución: secciones críticas Sistemas operativos: una visión aplicada de Miguel, F. Pérez Sistemas Distribuidos © J. Carretero, F. García, P.

Ejemplo con sección crítica void suma_parcial(int ni, int nf) { int j = 0; int suma = 0; for (j = ni; j <= nf; j++) suma = suma + j; <Entrada en la sección crítica> suma_total = suma_total + suma; <Salida de la sección crítica> pthread_exit(0); } • Cada proceso debe solicitar permiso para entrar en la sección crítica, mediante algún fragmento de código que se denomina entrada a la sección crítica. • Si un proceso sale de la sección crítica debe indicarlo en el fragmento de código denominado salida de la sección crítica. Sistemas operativos: una visión aplicada de Miguel, F. Pérez Sistemas Distribuidos © J. Carretero, F. García, P.

Ejemplo 3 void ingresar(char *cuenta, int cantidad) { int saldo, fd; fd = open(cuenta, O_RDWR); read(fd, &saldo, sizeof(int)); saldo = saldo + cantidad; lseek(fd, 0, SEEK_SET); write(fd, &saldo, sizeof(int)); close(fd); return; } • Si dos procesos ejecutan concurrentemente este código se puede perder algún ingreso. • Solución: secciones críticas Sistemas operativos: una visión aplicada de Miguel, F. Pérez Sistemas Distribuidos © J. Carretero, F. García, P.

Ejemplo 3 con sección crítica void ingresar(char *cuenta, int cantidad) { int saldo, fd; fd = open(cuenta, O_RDWR); <Entrada en la sección crítica> read(fd, &saldo, sizeof(int)); saldo = saldo + cantidad; lseek(fd, 0, SEEK_SET); write(fd, &saldo, sizeof(int)); <Salida de la sección crítica> close(fd); return; } Sistemas operativos: una visión aplicada de Miguel, F. Pérez Sistemas Distribuidos © J. Carretero, F. García, P.

Solución al problema de la sección crítica • Estructura general de cualquier mecanismo utilizado para resolver el problema de la sección crítica: Entrada en la sección crítica Código de la sección crítica Salida de la sección crítica • Requisitos: – Exclusión mutua: Si un proceso está ejecutando código de la sección crítica, ningún otro proceso lo puede hacer. – Progreso: Si ningún proceso está ejecutando dentro de la sección crítica, la decisión de qué proceso entra en la sección se hará sobre los procesos que quieren entrar. – Espera limitada: Debe haber un límite en el número de veces que se permite que los demás procesos entren a ejecutar código a la sección crítica después de que un proceso haya efectuado una solicitud de entrada y antes de que se conceda la suya. Sistemas operativos: una visión aplicada de Miguel, F. Pérez Sistemas Distribuidos © J. Carretero, F. García, P.

Problema del productor-consumidor • Ej. El compilador hace de funciones de productor al generar el código ensamblador que consumirá el proceso ensamblador para generar el código máquina. • Se debe sincronizar la comunicación. Si el mecanismo de comunicación se llena el productor se para hasta que el consumidor genere espacio. Sistemas operativos: una visión aplicada de Miguel, F. Pérez Sistemas Distribuidos © J. Carretero, F. García, P.

El problema de los lectores-escritores • Se da una combinación de procesos que leen y escriben sobre el recurso. Se dan las siguientes restricciones: • Sólo se permite acceso a un escritor al mismo tiempo. Ningún proceso lector o escritor puede acceder. • Se permite, que múltiples lectores tengan acceso al objeto ya que estos no modifican el contenido. Sistemas operativos: una visión aplicada de Miguel, F. Pérez Sistemas Distribuidos © J. Carretero, F. García, P.

Comunicación cliente-servidor Sistemas operativos: una visión aplicada de Miguel, F. Pérez Sistemas Distribuidos © J. Carretero, F. García, P.

Contenido • Introducción. • Tipos de procesos concurrentes. • Problemas clásicos de comunicación y sincronización. – – Sección crítica. Productor-consumidor. Lectores-escritores. Cliente-servidor. • Mecanismos de comunicación y sincronización. – – – Archivos. Tuberías. Llamadas al sistema para la gestión de tuberías. Semáforos. Llamadas al sistema para la gestión de semáforos. • Interbloqueos. Sistemas operativos: una visión aplicada de Miguel, F. Pérez Sistemas Distribuidos © J. Carretero, F. García, P.

Mecanismos de comunicación • Los principales mecanismos de comunicación que ofrecen los sistemas operativos son: • Archivos. • Tuberías. • Variables de memoria compartida. • Paso de mensajes. • Los principales mecanismos de sincronización que ofrecen los sistemas operativos son: • Señales. • Tuberías. • Semáforos. • Mutex y variables condicionales. • Paso de mensajes. Sistemas operativos: una visión aplicada de Miguel, F. Pérez Sistemas Distribuidos © J. Carretero, F. García, P.

Archivos Ventajas: • Permite comunicar un número ilimitado de procesos. Basta con que tengan permisos a los datos. • Los servidores de archivos ofrecen servicios sencillos y fáciles de utilizar. Inconvenientes: • Es un mecanismo poco eficiente, puesto que la lectura y escritura en disco son lentas. • Necesitan algún mecanismo que permita que los procesos se sincronicen en el acceso a los datos almacenados. Sistemas operativos: una visión aplicada de Miguel, F. Pérez Sistemas Distribuidos © J. Carretero, F. García, P.

Tuberías • Una tubería es un mecanismo de comunicación y sincronización. • Es como un pseudoarchivo mantenido por el SO. • Cada proceso ve la tubería como un conducto con dos extremos, uno de los cuales se utiliza para escribir o insertar datos y el otro para extraer o leer datos de la tubería. • El flujo de comunicación es unidireccional. • Para el caso bidireccional son necesarias dos tuberías. • Es un mecanismo con capacidad de almacenamiento. Tamaño típico 4 KB. Sistemas operativos: una visión aplicada de Miguel, F. Pérez Sistemas Distribuidos © J. Carretero, F. García, P.

Comunicación unidireccional con tuberías Sistemas operativos: una visión aplicada de Miguel, F. Pérez Sistemas Distribuidos © J. Carretero, F. García, P.

Comunicación bidireccional con tuberías Sistemas operativos: una visión aplicada de Miguel, F. Pérez Sistemas Distribuidos © J. Carretero, F. García, P.

Tuberías (POSIX) • Escritura en una tubería. – Si la tubería se encuentra llena o se llena durante la escritura, la operación bloquea el proceso escritor. – Si no hay ningún proceso con la tubería abierta para la lectura, la operación devuelve el correspondiente error. – Una operación de escritura sobre una tubería se realiza de forma atómica. • Lectura en una tuberia. – Si la tubería está vacía, la llamada bloquea la operación de lectura. – El número de datos involucrados debe ser menor que el tamaño de la tubería. • Existe tres forma de identificar una tubería. – Sin nombre: pipes – Con nombre: FIFOS • Sólo puede utilizarse entre los procesos hijos del proceso que creó el pipe int pipe(int fildes[2]); Sistemas operativos: una visión aplicada de Miguel, F. Pérez Sistemas Distribuidos © J. Carretero, F. García, P.

Tuberías (II) • read(fildes[0], buffer, n) – Pipe vacío se bloquea el lector – Pipe con p bytes • Si p ³ n devuelve n • Si p < n devuelve p – Si pipe vacío y no hay escritores devuelve 0 • write(fildes[1], buffer, n) – Pipe lleno se bloquea el escritor – Si no hay lectores se recibe la señal SIGPIPE • Lecturas y escrituras atómicas (cuidado con tamaños grandes) Sistemas operativos: una visión aplicada de Miguel, F. Pérez Sistemas Distribuidos © J. Carretero, F. García, P.

Sección crítica en tuberías • Consideremos la sección crítica de la forma siguiente: Leer dato de tubería < Seccion critica > escribir dato en la tubería • Una forma de resolver el problema de la sección crítica mediante tuberías consiste en insertar una operación de escritura con un dato de testigo. • Cuando varios procesos intenten ejecutar el fragmento de código de la sección crítica, sólo uno leerá y consumirá el dato que hace de testigo. • Además, existe progreso puesto que sólo los procesos que quieren entrar en al sección crítica para realizar una sentencia de lectura son los que ejecutan. • En general existe una espera limitada, ya que en algún momento el proceso bloqueado en dicha operación de lectura será elegido por el planificador del SO para ejecutar. Sistemas operativos: una visión aplicada de Miguel, F. Pérez Sistemas Distribuidos © J. Carretero, F. García, P.

Secciones críticas con tuberías void main(void) { int fildes[2]; char c; /* pipe para sincronizar */ /* se declara un carácter como testigo */ pipe(fildes); /* se crea un tubería */ write(fildes[1], &c, 1); /* Se inserta el testigo en la tubería*/ if (fork() == 0) { /* proceso hijo */ for(; ; ) { /* la operación read eliminará el testigo de la tubería */ read(fildes[0], &c, 1); /* entrada seccion critica */ < Seccion critica > write(fildes[1], &c, 1); /* salida seccion critica */ /* la operación write lo insertará de nuevo */ } Sistemas operativos: una visión aplicada de Miguel, F. Pérez Sistemas Distribuidos © J. Carretero, F. García, P.

Secciones críticas con tuberías (II) } else { /* proceso padre */ for(; ; ) { read(fildes[0], &c, 1); /* entrada seccion critica */ < seccion critica > write(fildes[1], &c, 1); /* salida seccion critica */ } } } Sistemas operativos: una visión aplicada de Miguel, F. Pérez Sistemas Distribuidos © J. Carretero, F. García, P.

Productor-consumidor con tuberías void main(void) { int fildes[2]; /* pipe para comunicar y sincronizar */ int dato_p[4]; /* datos a producir */ int dato_c; /* dato a consumir */ pipe(fildes); if (fork() == 0) { /* proceso hijo: productor */ for(; ; ) { < producir dato_p, escribe 4 enteros * write(fildes[1], dato_p, 4*sizeof(int)); } Sistemas operativos: una visión aplicada de Miguel, F. Pérez Sistemas Distribuidos © J. Carretero, F. García, P.

Productor-consumidor con tuberías (II) } else { /* proceso padre: consumidor */ for(; ; ) { read(fildes[0], &dato, sizeof(int)); /* consumir dato, lee un entero */ } } } Sistemas operativos: una visión aplicada de Miguel, F. Pérez Sistemas Distribuidos © J. Carretero, F. García, P.

Ejecución de mandatos con tuberías /* programa que ejecuta el mandato ``ls | wc'' */ void main(void) { int fd[2]; pid_t pid; /* se crea la tubería */ if (pipe(fd) < 0) { perror(``pipe''); exit(0); } pid = fork(); switch(pid) { case -1: /* error */ perror(``error en el fork''); exit(0); Sistemas operativos: una visión aplicada de Miguel, F. Pérez Sistemas Distribuidos © J. Carretero, F. García, P.

Ejecución de mandatos con tuberías (II) case 0: /* proceso hijo ejecuta ``ls'' */ /* duplica el descriptor de escritura fd. La llamada devuelve un nuevo descriptor de archivo. De esta forma se redirige el descriptor de salida estandar en el proceso hijo a la tubería */ /* cierra la salida estandar que inicialmente es un proceso referencia al terminal*/ dup 2(fd[1], STDOUT_FILENO); close(fd[0]); /* cierra el descriptor de lectura fd[0] */ /* se cierra el descriptor fd[1], ya que el proceso hijo no lo va ha utilizar */ close(fd[1]); /* aunque se cambia el proceso, se conserva el BCP de la tabla de descriptores de ficheros abiertos, y por tanto el el standard de salida que está referenciado a la tubería */ execlp(``ls'', NULL); Sistemas operativos: una visión aplicada de Miguel, F. Pérez Sistemas Distribuidos © J. Carretero, F. García, P.

Ejecución de mandatos con tuberías (II) perror(``execlp''); exit(-1); default: /* proceso padre ejecuta ``wc'' */ dup 2(fd[0], STDIN_FILENO); close(fd[0]); close(fd[1]); execlp(``wc'', NULL); perror(``execlp''); } } Sistemas operativos: una visión aplicada de Miguel, F. Pérez Sistemas Distribuidos © J. Carretero, F. García, P.

Ejecución de mandatos con tuberías (III) • Proceso • STDIN • STDOUT • fd[0] • fd[1] • STDOUT • pipe • STDOUT • ls Sistemas operativos: una visión aplicada de Miguel, F. Pérez • STDIN • STDOUT • fd[0] • fd[1] • redirección • Proceso hijo • STDIN • pipe • Proceso • STDIN • pipe • Proceso hijo • Proceso • STDIN • fork() • STDIN • STDOUT • fd[0] • fd[1] • pipe(fd) • STDIN • STDOUT • exec • STDOUT • Proceso hijo • STDIN • pipe • STDOUT • wc Sistemas Distribuidos © J. Carretero, F. García, P.

Tuberías con nombre en POSIX (FIFOS) • • Igual que los pipes Mecanismo de comunicación y sincronización con nombre Misma máquina Servicios – int mkfifo(char *name, mode_t mode); • Crea un FIFO con nombre name – int open(char *name, int flag); • Abre un FIFO (para lectura, escritura o ambas) • Bloquea hasta que haya algún proceso en el otro extremo • Lectura y escritura mediante read() y write() – Igual semántica que los pipes • Cierre de un FIFO mediante close() • Borrado de un FIFO mediante unlink() Sistemas operativos: una visión aplicada de Miguel, F. Pérez Sistemas Distribuidos © J. Carretero, F. García, P.

Semáforos • Un semáforo es un mecanismo de sincronización que se utiliza generalmente en sistemas de memoria compartida en una misma máquina. • Es un objeto con un valor entero, al que se le puede asignar un valor inicial no negativo. • Dos operaciones atómicas – Wait: bloquea el proceso – Signal: desbloquea el proceso • Si el valor del semáforo es menor o igual que cero, cualquier operación wait bloqueará el proceso. Si el valor es positivo no se bloqueará. • El número de procesos bloqueados en un instante determinado por wait, es el valor absoluto del semáforo si es negativo. • Si se ejecuta la operación signal, el valor del semáforo se incrementa y se desbloquea un proceso. Sistemas operativos: una visión aplicada de Miguel, F. Pérez Sistemas Distribuidos © J. Carretero, F. García, P.

Operaciones sobre emáforos wait(s) { } s = s - 1; if (s < 0) { <Bloquear al proceso> } signal(s) { s = s + 1; if (s <= 0) <Desbloquear a un proceso bloqueado por la operacion wait> } } Sistemas operativos: una visión aplicada de Miguel, F. Pérez Sistemas Distribuidos © J. Carretero, F. García, P.

Secciones críticas con semáforos wait(s); /* entrada en la seccion critica */ < seccion critica > signal(s); /* salida de la seccion critica */ • El semáforo debe tener valor inicial 1. Esto permite a un único proceso atender la sección crítica. • Si el valor inicial del semáforo fuera 2, entonces dos procesos podrían ejecutar la llamada wait sin bloquearse y por tanto su ejecución simultánea dentro de la sección crítica. Sistemas operativos: una visión aplicada de Miguel, F. Pérez Sistemas Distribuidos © J. Carretero, F. García, P.

Secciones críticas con semáforos Valor del semáforo (s) P 0 P 1 P 2 1 0 wait(s) -1 wait(s) -2 desbloquea -1 signal(s) desbloquea 0 signal(s) Ejecutando código de la sección crítica 1 Proceso bloqueado en el semáforo signal(s) • Se representan 3 procesos P 1, P 2, P 3 en una sección crítica con semáforo de valor inicial 1. Sistemas operativos: una visión aplicada de Miguel, F. Pérez Sistemas Distribuidos © J. Carretero, F. García, P.

Productor-consumidor con semáforos • Una forma de solucionar el problema de productor-consumidor en utilizar un almacén o cola circular compartido por ambos procesos. • El productor inserta datos en el buffer y el consumidor lo retira. • La solución es usando threads y semáforos. • Se define el problema como de tipo productor-consumidor con buffer circular y acotado. • Situaciones a evitar: – – – El consumidor saca elementos cuando el buffer está vacio. El productor coloca elementos en el buffer cuando éste se encuentra lleno. El productor sobrescribe un elemento que todavía no se ha sacado del buffer. El consumidor saca elementos del buffer que ya fueron sacados con anterioridad. El consumidor saca un elemento mientras el productor lo está insertando. • Cuando un proceso ligero necesita un recurso, decrementa el semáforo con wait. Si se libera el recurso, se incrementa el semáforo con signal. Sistemas operativos: una visión aplicada de Miguel, F. Pérez Sistemas Distribuidos © J. Carretero, F. García, P.

Productor-consumidor con semáforos (buffer acotado y circular) Sistemas operativos: una visión aplicada de Miguel, F. Pérez Sistemas Distribuidos © J. Carretero, F. García, P.

Semáforos POSIX • int sem_init(sem_t *sem, int shared, int val); – Inicializa un semáforo sin nombre • int sem_destroy(sem_t *sem); – Borra un semáforo con nombre. • int sem_wait(sem_t *sem); – Realiza la operación wait sobre un semáforo. • int sem_post(sem_t *sem); – Realiza la operación signal sobre un semáforo. Sistemas operativos: una visión aplicada de Miguel, F. Pérez Sistemas Distribuidos © J. Carretero, F. García, P.

Productor-consumidor con semáforos (II) #define MAX_BUFFER #define DATOS_A_PRODUCIR sem_t elementos; sem_t huecos; int buffer[MAX_BUFFER]; void main(void) { pthread_t th 1, th 2; 1024 100000 /* tamaño del buffer */ /* datos a producir */ /* elementos en el buffer */ /* huecos en el buffer */ /* buffer comun */ /* identificadores de threads */ /* inicializar los semaforos */ sem_init(&elementos, 0, 0); /* semáforos de elementos */ sem_init(&huecos, 0, MAX_BUFFER); Sistemas operativos: una visión aplicada de Miguel, F. Pérez Sistemas Distribuidos © J. Carretero, F. García, P.

Productor-consumidor con semáforos (III) /* crear los procesos ligeros */ pthread_create(&th 1, NULL, Productor, NULL); pthread_create(&th 2, NULL, Consumidor, NULL); /* esperar su finalizacion */ pthread_join(th 1, NULL); pthread_join(th 2, NULL); sem_destroy(&huecos); sem_destroy(&elementos); exit(0); } Sistemas operativos: una visión aplicada de Miguel, F. Pérez Sistemas Distribuidos © J. Carretero, F. García, P.

Productor-consumidor con semáforos (IV) void *Productor(void *p) /* codigo del productor */ { int pos = 0; /* posicion dentro del buffer */ int dato; /* dato a producir */ int i; for(i=0; i < DATOS_A_PRODUCIR; i++ ) { dato = i; /* producir dato */ sem_wait(&huecos); /* wait decrementa el semáforo huecos */ buffer[pos] = i; /* se inserta en el buffer */ pos = (pos + 1) % MAX_BUFFER; sem_post(&elementos); /*signal incrementa el semáforo elementos*/ } pthread_exit(0); } Sistemas operativos: una visión aplicada de Miguel, F. Pérez Sistemas Distribuidos © J. Carretero, F. García, P.

Productor-consumidor con semáforos (V) void *Consumidor(void *p) { int pos = 0; int dato; int i; /* codigo del Consumidor */ for(i=0; i < DATOS_A_PRODUCIR; i++ ) { sem_wait(&elementos); /* wait da un elemento menos */ dato = buffer[pos]; pos = (pos + 1) % MAX_BUFFER; sem_post(&huecos); /* signal da un hueco mas */ /* consumir el dato extraido*/ } pthread_exit(0); } Sistemas operativos: una visión aplicada de Miguel, F. Pérez Sistemas Distribuidos © J. Carretero, F. García, P.

Lectores-escritores con semáforos int dato = 5; /* recurso */ int n_lectores = 0; /* numero de lectores que se encuentran accediendo de forma simultanea al recurso compartido */ sem_t lectores; /* controlar el acceso n_lectores */ sem_t recurso; /* controlar el acceso a dato */ void main(void) { pthread_t th 1, th 2, th 3, th 4; sem_init(&recurso, 0, 1); /* inicializa el semáforo recurso */ sem_init(&lectores, 0, 1); /* inicializa el semáforo lectores */ pthread_create(&th 1, pthread_create(&th 2, pthread_create(&th 3, pthread_create(&th 4, Sistemas operativos: una visión aplicada de Miguel, F. Pérez NULL, Lector, NULL); Escritor, NULL); Sistemas Distribuidos © J. Carretero, F. García, P.

Lectores-escritores con semáforos (II) pthread_join(th 1, pthread_join(th 2, pthread_join(th 3, pthread_join(th 4, NULL); /* cerrar todos los semaforos */ sem_destroy(&recurso); sem_destroy(&lectores); exit(0); } Sistemas operativos: una visión aplicada de Miguel, F. Pérez Sistemas Distribuidos © J. Carretero, F. García, P.

Lectores-escritores con semáforos (III) /* codigo del lector */ void Lector(void) { /* codigo del lector */ sem_wait(&lectores); n_lectores = n_lectores + 1; if (n_lectores == 1) sem_wait(&recurso); /* wait */ sem_post(&lectores); /* signal */ printf(``%dn'', dato); /* leer dato */ sem_wait(&lectores); n_lectores = n_lectores - 1; if (n_lectores == 0) sem_post(&recurso); sem_post(&lectores); pthread_exit(0); } Sistemas operativos: una visión aplicada de Miguel, F. Pérez Sistemas Distribuidos © J. Carretero, F. García, P.

Lectores-escritores con semáforos (IV) /* código del escritor */ void Escritor(void) { sem_wait(&recurso); dato = dato + 2; sem_post(&recurso); /* codigo del escritor */ /* modificar el recurso */ pthread_exit(0); } Sistemas operativos: una visión aplicada de Miguel, F. Pérez Sistemas Distribuidos © J. Carretero, F. García, P.

Contenido • Introducción. • Tipos de procesos concurrentes. • Problemas clásicos de comunicación y sincronización. – – Sección crítica. Productor-consumidor. Lectores-escritores. Cliente-servidor. • Mecanismos de comunicación y sincronización. – – – Archivos. Tuberías. Llamadas al sistema para la gestión de tuberías. Semáforos. Llamadas al sistema para la gestión de semáforos. • Interbloqueos. Sistemas operativos: una visión aplicada de Miguel, F. Pérez Sistemas Distribuidos © J. Carretero, F. García, P.

Interbloqueos • Procesos compiten por recursos y se comunican entre sí • S. O. proporciona mecanismos de comunicación y sicronización • No basta: Conflicto entre necesidades de procesos puede causar bloqueo indefinido – Interbloqueo (deadlock) • Problema conocido y estudiado pero poca repercusión práctica • Aparece en otras disciplinas informáticas (p. e. Bases de datos) • Múltiples ejemplos de la vida cotidiana – Carretera de 2 sentidos con puente donde sólo cabe 1 coche – 2 personas llamándose por teléfono mutuamente • El interbloqueo surge debido a que se produce un conflicto en las necesidades de los dos vehículos: el recurso que necesita cada vehículo lo posee el otro. • Si otros vehículos intentan cruzar el puente quedarían implicados en el interbloqueo. Sistemas operativos: una visión aplicada de Miguel, F. Pérez Sistemas Distribuidos © J. Carretero, F. García, P.

Interbloqueos Estrategias para los interbloqueos: • Detección y recuperación. Se detecta el interbloqueo y uno de los vehículos libera el recurso que posee para que lo utilice el otro. • Solución: elegir uno de los sentidos de circulación y que los vehículos en sentido contrario den marcha atrás saliendo del puente. • Política para determinar que vehículos retroceden y se produce un gasto en trabajo realizado por una entidad. • Prevención o predicción. Existe un punto de no retorno a partir del cual el interbloqueo es inevitable. • Ej. Habiendo más de un vehículo en el puente, el interbloqueo se produce si un vehículo entra en sentido contrario. • Se plantean estrategias basadas en la prevención o predicción para evitar el interbloqueo. • Ej. Señalización mediante semáforos que indiquen cual es el sentido de paso en el puente. Sistemas operativos: una visión aplicada de Miguel, F. Pérez Sistemas Distribuidos © J. Carretero, F. García, P.

Interbloqueos • Interbloqueo se caracteriza por la existencia de: – Conjunto de entidades activas que usan un conjunto de recursos. • Entidades activas – Procesos y threads. • Recursos – Físicos: • UCPs, memoria, dispositivos. etc. – Lógicos: • archivos, semáforos, mutex, cerrojos, mensajes, señales, etc. Sistemas operativos: una visión aplicada de Miguel, F. Pérez Sistemas Distribuidos © J. Carretero, F. García, P.

Tipos de recursos • Reutilizables o consumibles – ¿Sigue existiendo después de usarse? • Uso dedicado o compartido – ¿Pueden usarlo varios procesos simultáneamente? • Con uno o múltiples ejemplares – ¿Existen múltiples ejemplares del mismo recurso? • Expropiables o no expropiables – ¿Es factible expropiar el recurso cuando se está usando? Sistemas operativos: una visión aplicada de Miguel, F. Pérez Sistemas Distribuidos © J. Carretero, F. García, P.

Interbloqueos • Todos los recursos físicos • Algunos lógicos (archivos, semáforos, mutex, . . . ) Primer ejemplo de interbloqueo Proceso P 1 Proceso P 2 Solicita(C) Solicita(I) Solicita(C) Uso de rec. Libera(I) Libera(C) Libera(I) Sistemas operativos: una visión aplicada de Miguel, F. Pérez Sistemas Distribuidos Ejecución con interbloqueo P 1: solicita(C) P 2: solicita(I) P 2: solicita(C) bloqueo P 1: solicita(I) Ejecución sin interbloqueo P 1: solicita(C) P 1: solicita(I) P 2: solicita(I) bloqueo P 1: libera(I) P 2: solicita(C) bloqueo P 1: libera(C) P 2: libera(I) © J. Carretero, F. García, P.

Definición de interbloqueo • Un conjunto de procesos está en interbloqueo si cada proceso está esperando un recurso que sólo puede liberar (generar, si son consumibles) otro proceso del conjunto. – No es requisito bloqueo: puede haber espera activa • Condiciones necesarias pero no suficientes para interbloqueo: – Exclusión mutua. Los recursos implicados deben tratarse para uso exclusivo. – Retención y espera. Mientras el proceso espera por recursos pedidos, mantiene los ya asignados. – Sin expropiación. No se expropian recursos asignados. Un proceso sólo libera sus recursos voluntariamente. – Espera circular. Existe lista circular de procesos tal que cada proceso espera por recurso que tiene siguiente proceso. Sistemas operativos: una visión aplicada de Miguel, F. Pérez Sistemas Distribuidos © J. Carretero, F. García, P.

Condición necesaria y suficiente • Idea base: Visión “optimista” del estado actual – Proceso no bloqueado debería devolver recursos en el futuro. – Recursos liberados desbloquearían otros procesos. – Esos procesos liberarían recursos desbloqueando a otros, etc. • Reducción del sistema por proceso P – Si se pueden satisfacer necesidades de P con recursos disponibles. – Nuevo estado hipotético donde P ha liberado todos sus recursos. • Condición necesaria y suficiente: – secuencia de reducciones desde estado actual que incluya a todos los procesos del sistema. – Si no: procesos no incluidos están en interbloqueo. • Estas condiciones son necesarias y suficientes si el sistema sólo hay una unidad en cada recurso. Sistemas operativos: una visión aplicada de Miguel, F. Pérez Sistemas Distribuidos © J. Carretero, F. García, P.

Tratamiento del interbloqueo • Detección y recuperación. Dejar que se produzca, detectarlo y recuperarse del mismo. – La activación del algoritmo de detección puede hacerse en cada petición insatisfecha o periódicamente dependiendo de las características del sistema. – La recuperación generalmente se basa en abortar alguno de los procesos implicados en el interbloqueo. – Detección implica coste de algoritmo + recuperación que conlleva una pérdida del trabajo realizado en ese momento por los procesos implicados. – El criterio a la hora de seleccionar qué procesos se abortan deberían intentar minimizar el coste asociado a la muerte prematura de los mismos. • Prevención. Asegura que no ocurre fijando reglas para pedir recurso. – Las técnicas de prevención se basan en asegurar que no se puede satisfacer una de las condiciones necesarias en el interbloqueo. – Las dos estrategias de prevención más frecuentes son la petición simultánea de recursos y la petición ordenada. – Infrautilización de recurso: se deben pedir antes de necesitarlos. Sistemas operativos: una visión aplicada de Miguel, F. Pérez Sistemas Distribuidos © J. Carretero, F. García, P.

Tratamiento del interbloqueo • Predicción. Asegura que no ocurre basándose en conocimiento de necesidades futuras de los procesos – Los algoritmos de predicción se basan en evitar que el sistema cruce el punto de no retorno que conduce al interbloqueo a partir de un conocimiento a priori de las necesidades máximas de cada proceso. – Un estado es seguro si el estado de asignación de recurso que resulta al considerar todos los procesos realizan en ese instante todas su posibles peticiones, está libre de interbloqueos. – La estrategia de predicción consiste en que cada vez que un proceso realiza un solicitud de recursos que están disponibles, sólo se le concede si el estado resultante es seguro. En caso de que no lo sea, se bloquea el proceso si asignarle los recursos. – No reflejan el uso exacto de los recursos durante la ejecución de los mismos, y causan una infrautilización de los recursos. – Coste de algoritmo + Infrautilización de recursos • Ignorar el problema: Utilizada por la mayoría de los SS. OO. – Dada la baja probabilidad de que ocurra y el coste que conlleva evitarlo (infrautilización y/o coste de algoritmos). Sistemas operativos: una visión aplicada de Miguel, F. Pérez Sistemas Distribuidos © J. Carretero, F. García, P.

Prevención basada en evitar “retención y espera” • Sólo pueden solicitarse recursos si no se tiene ninguno asignado – Infrautilización t 1: solicita(A, B, C) (t 1, t 2): sólo utiliza A (t 2, t 3): utiliza A y B t 3: Libera(A) (t 3, t 4): sólo utiliza B (t 4, t 5): utiliza B y C t 5: Libera(B) (t 5, t 6): sólo utiliza C t 6: Libera(C) t 7: solicita(D) (t 7, t 8): sólo utiliza D t 8: Libera(D) Sistemas operativos: una visión aplicada de Miguel, F. Pérez Sistemas Distribuidos © J. Carretero, F. García, P.

Prevención basada en evitar “espera circular” • Método de las peticiones ordenadas: – Se establece un orden total de los recursos del sistema – Restricción: Proceso sólo puede pedir recursos en orden – Conlleva infrautilización • En ejemplo anterior: – Si A<B<C<D Proceso pide justo cuando necesita – Si A>B>C>D Proceso pide todo en t 1 • Se deben ordenar recursos según orden más frecuente de uso Sistemas operativos: una visión aplicada de Miguel, F. Pérez Sistemas Distribuidos © J. Carretero, F. García, P.

Predicción del interbloqueo • Existencia de “punto de no retorno” Proceso P 1 Proceso P 2 Solicita(C) Solicita(I) Solicita(C) Uso de rec. Libera(I) Libera(C) y. Libera(C) P 2 obtienen su primer recurso Libera(I) • Si P 1 habrá interbloqueo • Se evita conociendo a priori plan de peticiones de cada proceso • No concede 1 de esas peticiones aunque recursos disponibles • El sistema debe estar siempre en un “estado seguro” Sistemas operativos: una visión aplicada de Miguel, F. Pérez Sistemas Distribuidos © J. Carretero, F. García, P.

Concepto de estado seguro • “Aunque todos los procesos solicitasen en este momento sus necesidades máximas, existe un orden secuencial de ejecución tal que cada proceso pueda obtenerlas” • Similar al análisis “futuro” de algoritmo de detección – Pero usando necesidades máximas en vez de peticiones actuales • Estado seguro: No interbloqueo usando como solicitudes necesidades máx. • Conocimiento a priori no da información sobre uso real Proceso P 1 Proceso P 2 Solicita(C) Solicita(I) Libera(C) Solicita(C) Ejemplo: no hay interbloqueo y Solicita(I) sí estado inseguro Libera(C) Libera(I) Sistemas operativos: una visión aplicada Sistemas Distribuidos © J. Carretero, F. García, P. de Miguel, F. Pérez Libera(I) Estado inseguro condición necesaria pero no suficiente

Tratamiento del interbloqueo en los SS. OO. • Mayoría lo ignora o no da una solución general • Distinción entre dos tipos de recursos: – Recursos internos (propios del S. O. ) • • Usados por un proceso en modo sistema Uso restringido a ejecución de una llamada Ej. semáforo interno para acceder a t. de procesos o buffer Interbloqueo puede causar colapso del sistema – Recursos de usuario • • Usados por un proceso en modo usuario Uso durante tiempo impredecible Ej. dispositivo dedicado o semáforo de aplicación Interbloqueo afecta a procesos y recursos involucrados Sistemas operativos: una visión aplicada de Miguel, F. Pérez Sistemas Distribuidos © J. Carretero, F. García, P.

Tratamiento del interbloqueo en los SS. OO. • Tratamiento de recursos internos – Código del S. O. es algo que apenas se modifica • Se puede estudiar a priori uso de recursos – Interbloqueo error de programación de S. O. – Uso de estrategias de prevención es adecuado • Dado que tiempo de uso es breve y acotado • Tratamiento de recursos de usuario – Código de procesos que usan recursos es impredecible – No hay tratamiento general para todos los recursos – Prevención Infrautilización – Predicción Dificultad de conocer información a priori – Detección y recuperación Demasiada sobrecarga Sistemas operativos: una visión aplicada de Miguel, F. Pérez Sistemas Distribuidos © J. Carretero, F. García, P.