Concurrencia y Exclusión Mutua

Agenda Procesos secuenciales Procesos concurrentes Multiprogramación, multiprocesamiento y procesamiento distribuido Interacción y sincronización procesos Corutinas, fork-join y cobegin-coend Exclusión mutua, sección crítica y condición de competencia Soluciones problema exclusión mutua

Programas secuenciales Especifica una ejecución secuencial de una lista de enunciados La ejecución del programa da como resultado la creación de un proceso

Procesos concurrentes Concurrencia: del verbo concurrir, asistir o acudir al mismo lugar o tiempo Especifica dos o más programas secuenciales ejecutados concurrentemente como procesos paralelos

Características procesos concurrentes Los procesos son concurrentes si existen simultáneamente Pueden funcionar en forma totalmente independiente, unos de otros Pueden ser asincronos lo cual significa que en ocasiones requieren cierta sincronización y cooperación

Clasificación procesos concurrentes Podemos hablar de multiprogramación, multiprocesamiento o procesamiento distribuido

Multiprogramación Los procesos son ejecutados, concurrentemente, compartiendo uno o más procesadores (c/u con su memoria) El kernel del sistema operativo multiplexa los procesos en los procesadores Proc7 M1 CPU1 Proc1 Proc6 Proc2 M2 CPU2 Proc5 Proc3 Proc4

Multiprocesamiento Se ejecuta un proceso en cada procesador Los procesos comparten una memoria en común CPU1 CPU2 CPU3 Memoria común CPU4 Proc1 Proc2 Proc4 Proc3

Procesamiento distribuido Los procesos están conectados a través de una red de comunicación Cada procesos cuenta con su memoria Proc1 Proc2 Proc3 Proc4 CPU1 CPU2 CPU3 CPU4 M1 M2 M3 M4 red de comunicación

Interacción entre procesos Para poder cooperar, procesos concurrentes deben comunicarse y sincronizarse Comunicación permite ejecución de un proceso para influenciar ejecución de otro Comunicación entre procesos esta basada en el uso de variables compartidas o envío de mensajes

La sincronización Frecuentemente, la sincronización es necesaria cuando los procesos se comunican Procesos son ejecutados con velocidades impredecibles Para comunicarse un proceso debe realizar una acción que el otro pueda detectar

la acción puede ser asignar un valor a una variable o enviar un mensaje esto solo trabaja si el “realizar una acción” es anterior al “detectar una acción” Entonces la sincronía puede verse como un conjunto de restricciones para el ordenamiento de eventos Programador usa un mecanismo de sincronía para retardar ejecución de un proceso para satisfacer una restricción

Notación expresar concurrencia Como indicar una ejecución concurrente Que modo de comunicación entre procesos se va a utilizar Cual mecanismo de sincronización se va a usar

Especificando ejecución concurrente Existen varias notaciones Importante diferenciar: la definición del proceso de la sincronización del proceso Proposiciones recientes separan estos conceptos diferentes y contienen restricciones sintácticas, que imponen una estructura del programa concurrente

La estructura del programa permite localizar los segmentos que pueden ejecutarse concurrentemente Entre las más comunes: corutinas fork-join el enunciado co-begin Pueden usarse para especificar un número estático o dinámico de procesos

Corutinas Propuestas por Conway en 1963 Corutinas son subrutinas que permiten una transferencia de control de una forma simétrica más que jerárquica Cada corutina puede ser vista como la implementación de un proceso Bien usadas, son un medio para organizar programas concurrentes que comparten un mismo procesador

Elementos corutinas El enunciado resume El enunciado call transfiere control a la corutina mencionada guarda información necesaria para controlar la ejecución de regreso El enunciado call inicializa el cálculo de la corutina El enunciado return transfiere el control de regreso al procedimiento que realizó un call

Ejemplo corutinas Program P; ------------- call A; end corutina A resume B; corutina B ------------- resume A; return;

La ejecución P Corutina A Corutina B call A resume B resume A resume B return end

Comentarios corutinas La ejecución, por parte de un proceso, de resume provoca una sincronización No son adecuadas para un verdadero procesamiento paralelo Son procesos concurrentes en el que el “switcheo de procesos” ha sido completamente especificado y no dejado al kernel o a la implementación Lenguajes: SIMULA I y SL5

Enunciados fork-join Enunciado fork especifica que una rutina puede empezar su ejecución La rutina invocada y la rutina invocadora proceden concurrentemente Para sincronizar invocada e invocadora, esta última puede ejecutar un join Enunciado join retrasa ejecución rutina invocadora hasta que la rutina invocada termine

Ejemplo fork-join program P1 ------------- program P2 <codigo 1> fork P2; <codigo 2> join P2; <codigo 3> program P2 ------------- end

La ejecución P1 P2 código 1 fork P2 código 2 join P2 end código 3

Comentarios fork-join Enunciados fork-join puede aparecer en condicionales y ciclos es necesario entender bien la ejecución del programa, para saber que rutinas se van a ejecutar concurrentemente Cuando se usa de forma disciplinada los enunciados son prácticos y poderosos fork proporciona un mecanismo para la creación dinámica de procesos enunciados similares también están incluidos en PL/I y Mesa

El enunciado cobegin Es una forma estructurada de denotar una ejecución concurrente Por ejemplo: denota una ejecución concurrente de S1, S2, … Sn cada uno de los Si’s puede ser cualquier enunciado incluyendo un cobegin o un bloque con declaraciones locales cobegin S1 || S2 || … || Sn coend

Características cobegin La ejecución de un cobegin solo termina cuando la ejecución de todos los Si’s terminó No es tan potente como fork-join, pero es suficiente para especificar la mayor parte de los cálculos concurrentes Sintaxis hace explícito cuales rutinas son ejecutadas concurrentemente Variantes implementadas en ALGOL68, CSP, Edison y Argus

Comunicación y sincronización procesos Procesos requieren comunicación entre ellos. Procesamiento distribuido envío/recepción de mensajes Multiprocesamiento: pipes: salida proceso es entrada de otro uso de variables compartidas o de algún espacio en común donde puedan leer o escribir los procesos

Ejemplo: spooler impresión Cuando un proceso desea imprimir un archivo escribe el nombre de este en un directorio Otro proceso, demonio impresión (lpd) verifica si existen archivos por imprimir, los imprime y elimina sus nombres del directorio

Elementos spooler impresión : 4 5 6 7 toto.c prog.c tarea.txt out = 4 Pa in = 7 Pb : Pa desea imorimir t1 Pb desea imorimir t2

Pasos en impresión archivos Proceso A Proceso B lee valor in y almacena en next next := 7 termina quantum lee valor in y almacena en sig sig := 7 actualiza valor in (in = 8) escribe t2 en localidad 7 sale y hace otras cosas actualiza valor in (in = 8) escribe t1 en localidad 7 sale y hace otras cosas termina quantum

Condición de competencia Dos o más procesos leen y/o escriben en ciertos datos compartidos y el resultado final depende de quien ejecuta qué y en qué momento Solución: prohibir que uno o más procesos escriba en los datos compartidos a la vez

La exclusión mutua Garantizar que si un proceso utiliza una variable o algún recurso compartido, los demás no podrán usarlos al mismo tiempo Conocida como mutex Cada proceso debe verificar que durante cierta parte del tiempo, puede tener acceso a la memoria compartida de archivos o realizando labores críticas que pueden llevar a conflictos

Sección crítica Parte del código en el cual se tiene acceso a una variable o archivo compartido Corolario: si dos procesos no están al mismo tiempo en sección crítica, podemos evitar las condiciones de competencia

Asignación recursos Sean n procesos que entran en conflicto por el acceso a un recurso único no compartible Recurso a usar en sección crítica Necesario usar un protocolo formado de tres partes: protocolo de adquisición <uso del recurso en sección crítica> protocolo de liberación

Posibles problemas Interbloqueo: los procesos se bloquean entre si y nadie tiene acceso al recurso, no hay actividad en ninguno de los procesos si estoy solo paso si no: dejo pasar a los demás Hambruna (starvation) sean tres procesos: P1 P2 y P3 si el recurso siempre se le asigna, alternativamente, a P1 y P2, P3 no tendrá acceso a él

Condiciones solución mutex Dos procesos no deben encontrarse al mismo tiempo dentro de sus secciones críticas No se deben hacer hipótesis sobre la velocidad o el número de CPUs Ninguno de los procesos que estén en ejecución fuera de su SC puede bloquear a otros procesos Ningún proceso debe esperar eternamente para entrar a su SC

Posibles soluciones Des-activación de interrupciones Variables de cerradura Alternancia estricta Esperando que el otro termine Cediendo el lugar al otro Esperando un tiempo aleatorio Algoritmo de Dekker Algoritmo de Peterson

Des-activación interrupciones Solución más simple: cada proceso desactivará todas sus interrupciones justo antes de entrar en sección crítica y las activará al salir de ella Con las interrupciones desactivadas no puede ocurrir una interrupción de reloj Problema: un proceso (usuario) podría desactivarlas y nunca activarlas de nuevo Si hay más de dos CPUs, la desactivación sólo afecta a uno de ellos

Variables de cerradura Antes proceso entre a su sección crítica se hace prueba a una variable tipo cerradura: si esta es 0: proceso la cambia a 1 y entra a su sección crítica si esta es 1: espera hasta que la variable cambie su valor a 0 Problema proceso P1 lee un valor de 0 antes modifique el valor se le acaba el quatum proceso P2 también va a leer un valor de 0 se van a tener dos procesos en S.C.

Alternancia estricta void proc2() void proc1() { { while (TRUE) { while (turno != 1); seccion_critica(P2); turno=0; fuera_sec_crit(P2); } void proc1() { while (TRUE) { while (turno != 0); seccion_critica(P1); turno=1; fuera_sec_crit(P1); } main(){ turn=1; cobegin proc1 || proc2() coend }

Detalles alternacia estricta La prueba de una variable, en espera de que tome cierto valor se conoce como espera activa esto provoca un desperdicio del CPU ¿Qué pasa cuando uno de los procesos es más lento que el otro? en lo que proc1 ejecuta fue_sec_crit(p1) el proceso proc2 ejecuta sec_crit(p2), cambia valor a turno, ejecuta fue_sec_crit(p2) y regresa al while se van a tener un proceso bloqueado por otro que no esta en su sección crítica

Esperando que el otro termine int p1in, p2in; void proc1() { while (TRUE) { while (p2in == 1); p1in = 1; sección_critica_P1(); p1in = 0; out_sec_critica_P1(); }

Comentarios Dos variables ¿Qué pasa si se ejecuta en tandem? p1in: proceso 1 en sección crítica p2in: proceso 2 en sección crítica ¿Qué pasa si se ejecuta en tandem? se van a tener dos procesos en sección crítica

Cediendo el lugar al otro int p1deseaentar, p2deseaentrar; void proc1() { while (TRUE) { p1deseaentrar = 1; while (p2deseaentrar == 1); sección_critica_P1(); p1deseaentrar = 0; out_sec_critica_P1(); }

Comentarios El proceso indica su deseo de entrar a sección crítica Si el otro proceso también quiere entrar le cede el paso Problema ejecución tandem: si cada proceso asigna un 1 a su bandera antes de verificar, cada proceso encontrará la bandera del otro con valor 1 los dos entrarán en un ciclo infinito se da un bloqueo mutuo (interbloqueo o deadlock)

Esperando un tiempo aleatorio int p1deseaentar, p2deseaentrar; void proc1() { while (TRUE) { p1deseaentrar = 1; while (p2deseaentrar == 1) { p1deseaentrar = 0; retraso(aleatorio, algunosciclos); } sección_critica_P1(); out_sec_critica_P1(); }

Comentarios Se obliga a cada proceso a asignar repetidamente el valor falso a su bandera por periodos cortos, calculados de forma aleatoria Problema: una ejecución tandem y que el valor aleatorio será el mismo para los dos procesos Situación muy poco probable pero posible