Tema 6: Concurrencia de Procesos

Tema 6: Concurrencia de Procesos
Sistemas Operativos Tema 6: Concurrencia de Procesos

Índice: Cooperación de procesos Concurrencia y Sección Crítica Control Pesimista y Optimista de la Concurrencia Métodos basados en Impedir la Conmutación Métodos de Espera Ocupada Problemas de la Espera Ocupada Tema 6: Concurrencia de Procesos 2

1. Cooperación de Procesos Tema 6: Concurrencia de Procesos Relación entre los procesos en un sistema multiprogramado: Competencia (procesos independientes) Cooperación Procesos que cooperan: Colaboran en la consecución de algún fin Comparten recursos Tipos de recursos: Consumibles (un solo uso) Reutilizables en serie

1. Cooperación de Procesos Tema 6: Concurrencia de Procesos Formas de acceso a los recursos compartidos: Concurrencia Acceso simultáneo directo al recurso Sincronización Uso de mecanismos de coordinación para ordenar acceso Comunicación Sólo un proceso accede directamente a recurso Demás procesos le envían peticiones (cliente/servidor) Si quieres, puedes hacer notar que Programación Concurrente no tiene nada ver con el significado de concurrencia aquí. MUY IMPORTANTE: Deja claro que los mecanismos de control de concurrencia que se va a ver en este capítulo, son sólo para usar en aquellos casos en que el SO no proporciona primitivas a tales efectos, por ejemplo, cuando se está construyendo el propio SO. La modificación concurrente del estado de un recurso puede dar lugar a condiciones de carrera!

1. Concurrencia y Sección Crítica Tema 6: Concurrencia de Procesos … tabla[i]= e1; i= i+1; ... P1 … tabla[i]= e2; i= i+1; ... P2 1 2 3 tabla e1 e2 i=2 i=1 i=0 Contar que vamos a justificar la necesidad de mecanismos de coordinación, viendo un ejemplo de actualización concurrente de un recurso compartido Una vez seguida la traza, cuenta que esto es una condición de carrera. Condición de carrera: corrupción del estado de un recurso causada por su actualización concurrente por parte de varios procesos (o hilos).

1. Concurrencia y Sección Crítica Tema 6: Concurrencia de Procesos Sección crítica: porción de código en la que se accede a un recurso compartido. Exclusión mutua: garantizar que en cada momento se pueda estar ejecutando como máximo una sección crítica asociada a un recurso. Deja claro que la sección/región crítica siempre es referida a un recurso compartido. Protocolo de entrada: Comprobar si algún otro proceso está ejecutando su sección crítica Si lo hay, esperar Si no, entrar Protocolo de salida: Si hay procesos en espera, permitir la entrada a uno 1 2 3 tabla i=0 … tabla[i]= e1; i= i+1; ... P1 … tabla[i]= e2; i= i+1; ... P2 <protocolo de entrada> <protocolo de entrada> <protocolo de salida> <protocolo de salida>

1. Concurrencia y Sección Crítica Tema 6: Concurrencia de Procesos Requisitos de la exclusión mutua: Nunca debe haber más de un proceso ejecutando su sección crítica asociada a un mismo recurso. Todo proceso permanece tiempo finito en sección crítica. Ningún proceso suspendido, detenido o abortado fuera de sección crítica debe impedir la entrada a otro proceso. Ningún proceso esperará eternamente a entrar en sección crítica Si ningún proceso está ejecutando su sección crítica, cualquier proceso podrá hacerlo inmediatamente. Si hay procesos esperando para entrar en sección crítica y el proceso que la estaba ejecutando sale, uno de los que esperan entrará inmediatamente. No se pueden hacer suposiciones respecto a las velocidades relativas de ejecución de los procesos. Aclarar que lo último es una consideración general, no un requisito.

3. Control Pesimista y Optimista de la Conc. Tema 6: Concurrencia de Procesos Control Pesimista: Consiste en garantizar la exclusión mutua en el acceso a los recursos. Control Optimista: No se fuerza exclusión mutua → pueden darse condiciones de carrera!! Si se dan las condiciones de carrera, se detecta y se solucionan. Protocolo de entrada típico: salvar estado Protocolo de salida típico: Comprobar de ha habido condición de carrera En caso afirmativo, restaurar estado y repetir Aclarar que en el control optimista se basa en considerar que es poco probable que se produzcan condiciones de carrera

3. Control Pesimista y Optimista de la Conc. Tema 6: Concurrencia de Procesos Control Pesimista: Ventajas: Siempre es viable Inconvenientes: Fuerza esperas (posiblemente innecesarias) Algunos métodos pueden ser muy drásticos Control pesimista: Lo de que las esperas en el control pesimista sean posiblemente innecesarias, se refiere al hecho de que porque haya concurrencia no necesariamente tiene por qué haber condición de carrera. Control optimista: Lo del mayor grado de paralelismo se refiere a que a que se puede ejecutar concurrentemente la sección crítica, pues no fuerza esperas. Comentar que el nada impide que un cálculo deba repetirse un nº de veces arbitrariamente grande Control Optimista: Ventajas: Mayor grado de paralelismo Inconvenientes: Será posible o no en función de la naturaleza del recurso Si hay muchos procesos concurrentes, el nº de conflictos puede aumentar y por tanto el nº de repeticiones

3. Control Pesimista y Optimista de la Conc. Tema 6: Concurrencia de Procesos ¿Control Pesimista u Optimista? Depende de… Frecuencia y variabilidad de la probabilidad de condiciones de carrera Coste de la repetición del cálculo Optimista: idóneo si… Coste de repetición del cálculo es pequeño, y Previsible que hayan pocas condiciones de carrera Cuando hables del coste de la repetición del cálculo, aclara que es posible incluso que no sea viable. Pesimista: idóneo si… Coste de repetición del cálculo es grande, y Previsible que hayan muchas condiciones de carrera, o se espera variabilidad en su frecuencia

4. Métodos basados en impedir la conmut. Tema 6: Concurrencia de Procesos Pesimismo extremo: impide apropiación en sección crítica Mecanismos NO disponibles para procesos de usuario Posibilidades: Desactivar interrupciones Uso exclusivo del procesador Recordar la ventaja del determinismo de los métodos de planificación no apropiativos. Se consigue que la planificación se comporte como no apropiativa. Hacer notar que el hecho de no haya conmutación, garantiza exclusión mutua no ya sólo con los procesos que comparten región crítica, sino con todos.

4. Métodos basados en impedir la conmut. Tema 6: Concurrencia de Procesos Desactivar Interrupciones Si no hay interrupciones→no hay apropiación <protocolo de entrada> … [ sección crítica ] … <protocolo de salida> deshabilitar_interrupciones(); Recuerda que una apropiación puede ocurrir por Que un proceso en estado bloqueado pasa a estado preparado Termina una ranura de tiempo … y ambas cosas se provocan por una interrupción Inconvenientes: Mientras interrupciones deshabilitadas, Control absoluto de la máquina No se atienden dispositivos Puede que no se refresque la memoria Sistema en peligro! ¿Y la NMI? ¿Y si hay otros procesadores? habilitar_interrupciones();

4. Métodos basados en impedir la conmut. Tema 6: Concurrencia de Procesos Suspender la conmutación Pedir a planificador que suspenda conmutación hasta nueva orden ¡Ya no hay problemas con… Dispositivos Refresco de memoria <protocolo de entrada> … [ sección crítica ] … <protocolo de salida> suspender_conmutacion(); Recuerda que la llamada desactivar_conmutación() no debe estar disponible a procesos de usuario Recuerda que lo de la organización micronúcleo también es aplicable al anterior método de desactivar interrupciones reanudar_conmutacion(); Inconvenientes: Posibilidad condición de carrera con rutinas de interrupción Tampoco es adecuado para multiprocesadores ¡Cuidado en sistemas con organización micronúcleo!

5. Métodos de espera ocupada Tema 6: Concurrencia de Procesos Espera ocupada (o espera activa) esperar a que algo ocurra realizando continuas comprobaciones: Métodos de espera ocupada: Cerrojos Alternancia estricta Algoritmo de Dekker Algoritmo de Peterson Algoritmo de Lamport Instrucciones especiales … variable= 0; while(variable==0); Haz notar que en ausencia de una planificación apropiativa, una espera ocupada implica el cuelgue de la máquina

5. Métodos de espera ocupada Tema 6: Concurrencia de Procesos Cerrojos Variable compartida que indica si recurso está libre u ocupado: Contar lo que ocurre si se produce apropiación en lugar marcado, y que este mecanismo tan simple necesita apoyo adicional por parte del hardware para que funcione. Comentar que en apuntes vienen un montón de intentos de hacer funcionar esto, todos avocados al fracaso Vars. compartidas: int cerrojo=0; <protocolo de entrada> … [ sección crítica ] … <protocolo de salida> while(cerrojo); cerrojo= 1; cerrojo= 0; ¡Fallo! No hay atomicidad entre comprobación y cierre

5. Métodos de espera ocupada Tema 6: Concurrencia de Procesos Alternancia Estricta Caso de que dos procesos usen recurso por turnos Variable compartida que indica a qué proceso le toca: <protocolo de entrada> … [ sección crítica ] … <protocolo de salida> P1 <protocolo de entrada> … [ sección crítica ] … <protocolo de salida> P2 Comenta cómo de fácil se generaliza a N procesos Vars. compartidas: int turno=P1; while(turno !=P1); while(turno !=P2); turno= P2; turno= P1; ¡Funciona! Más restrictivo que cerrojos: un proceso nunca se da paso a sí mismo.

5. Métodos de espera ocupada Tema 6: Concurrencia de Procesos Alternancia Estricta Ventajas: Sencillez Aplicable en muchos contextos Inconvenientes: ¡Obliga a que alternancia sea estricta! Esto atenta contra requisito 3 exclusión mutua: “Ningún proceso suspendido, detenido o abortado fuera de sección crítica debe impedir la entrada a otro proceso”

5. Métodos de espera ocupada Tema 6: Concurrencia de Procesos Algoritmo de Dekker Si los dos procesos interesados→ se alternan Si uno no está interesado→ el otro puede usar recursos tantas veces como quiera Comprobación a dos niveles: Comenta que a partir de aquí, los algoritmos funcionan porque hacen uso de un protocolo de comprobación con tantos niveles como procesos se coordinan Primero se comprueba el interés del compañero, y en segundo lugar, se comprueba si ambos tiene interés, quién tiene preferencia interesado1=1; while (interesado2) { if (preferente==P2) { interesado1= 0; while (preferente==P2); interesado1=1; } } [ sección crítica ] preferente=P2; interesado1=0; P1 interesado2=1; while (interesado1) { if (preferente==P1) { interesado2= 0; while (preferente==P1); interesado2=1; } } [ sección crítica ] preferente=P1; interesado2=0; P2 Vars. compartidas: int interesado1=0; int interesado2=0; int preferente= P1;

5. Métodos de espera ocupada Tema 6: Concurrencia de Procesos Algoritmo de Peterson Equivalente a algoritmo de Dekker Reescrito de forma más clara, una rutina para protocolo de entrada y otra para protocolo de salida: Equivalencia entre variable “ultimo” y anterior “preferente”: El preferente no es el últimto. En el vector “interesado”, cada proceso escribe en su posición, y lee la de los demás. Si ambos procesos entran a la vez en protocolo_entrada, Es porque ambos están interesados, Pero sólo uno de ellos será el último en hacer ultimo=proc -> ése es el que espera. Comenta que este algoritmo es generalizable a N procesos, en apuntes viene, pero mejor pasamos a Lamport Vars. compartidas: int interesado[2]={0,0} int ultimo=0; void protocolo_entrada(int proc) { int otro= 1-proc; interesado[proc]= 1; ultimo= proc; while {(interesado[otro] == 1) && (ultimo==proc)); } void protocolo_salida(int proc) { interesado[proc]= 0; }

5. Métodos de espera ocupada Tema 6: Concurrencia de Procesos Algoritmo de Lamport (o de la panadería) Coordina a N procesos Cuando más de un proceso interesado en recurso: Ordena el acceso por turnos Una etapa de espera por cada proceso interesado Si eligiendo[i] != 0, no se debe tener en cuenta el valor de turno[i] Idea de funcionamiento: Eligiendo[i] != 0 ↔ proceso i está elgiendo turno (turno[i] no es válido todavía) Si turno[i] = 0 → proceso i no está interesado en entrar en sección crítica Si turno [i] > 0 → proceso i está interesado y su turno es turno[i] Vars. compartidas: int eligiendo[N]= {0,0,…,0} int turno[N]= {0,0, …,0};

5. Métodos de espera ocupada Tema 6: Concurrencia de Procesos Algoritmo de Lamport (o de la panadería) void protocolo_entrada(int proc) { /* Elegir turno */ eligiendo[proc]= 1; turno[proc]= 1 + mayor(turno); eligiendo[proc]= 0; /* Esperar a los que vayan por delante */ for (j=0; j< N; j++) if (j != proc) /* Si está eligiendo, esperar a ver qué turno saca */ while (eligiendo[j] !=0); /* Si tiene turno y es anterior a nosotros, esperar */ while ((turno[j] != 0) && anterior (turno[j], j, turno[proc], proc)); } La rutina mayor() da el valor máximo de un vector Nótese que la espera si está sacando turno es necesaria, pues podemos haber adelantado a un proceso que tenga un turno anterior a nosotros y haya quedado suspendido justo antes de bajar su bandera de eligiendo. Anterior: pueden haber dos turnos iguales dado que la elección de turno no es atómica. En dicho caso, por convenio, tiene prioridad por ejemplo el proceso con el índice más pequeño. void protocolo_salida(int proc) { /* Nos deshacemos del turno */ turno[proc]= 0; }

5. Métodos de espera ocupada Tema 6: Concurrencia de Procesos Instrucciones especiales: Test and Set (TS, TAS…) Soluciona el problema de atomicidad de los cerrojos Formato: TS operando (IBM 360) Z ← operando == 0 operando ← 1 Recalca que es atómica prot_entrada: TS cerrojo BNF prot_entrada RETN Único problema: otro master en el bus Solución: variantes que bloquean el bus

5. Métodos de espera ocupada Tema 6: Concurrencia de Procesos Instrucciones especiales: Intercambiar (XCHG) Puede funcionar de forma equivalente a TS Formato: XCHG registro, direccion (80x86) registro ↔ dirección Se puede reforzar con prefijo lock También es atómica Mismas consideraciones que TAS prot_entrada: MOV AL, lock XCHG AL, cerrojo CMP AL, 0 JNE prot_entrada RET

5. Métodos de espera ocupada Tema 6: Concurrencia de Procesos Instrucciones especiales: Comparar e Intercambiar (CS) Soporte para estrategias optimistas Formato: CS previo, nuevo, global (IBM 370) global: variable compartida que se actualiza previo: valor que tenía global antes de actualización nuevo: nuevo valor tentativo calculado para actualizar global ¿previo=global? actualizar ccr global←nuevo previo←global Sí No MOVE previo,global calculo: …. …. CS previo, nuevo, global BNEQ calculo

6. Problemas de la espera ocupada Tema 6: Concurrencia de Procesos Desperdicio de tiempo de CPU. Sólo admisible en: Procesadores dedicados Sistemas monoprogramados En el núcleo del SO, si se puede garantizar que tiempo de espera es suficientemente inferior a tiempo de conmutación Si se coordinan procesos con diferentes prioridades: Aclarar (click) que en un sistema monoprogramado puede haber espera ocupada para coordinar a un programa con una rutina de servicio de interrupción Aclarar que prioridad no se refiere sólo a prioridades tales como las vistas en planificación con prioridades, sino siempre que hayan procesos con más preferencia por usar la CPU que otros. Aclarar que lo expuesto para cerrojos vale para cualquier otro método con espera ocupada…. Seguir la traza de la animación, y comentar que esto es un interbloqueo: P1 tiene el recurso y P2 la CPU. Prioridad(P2) > Prioridad(P1) : while(cerrojo); cerrojo=1; : : : cerrojo=0; : P1 : while(cerrojo); cerrojo=1; : : : cerrojo=0; : P2 cerrojo=0 cerrojo=1

Tema 6: Concurrencia de Procesos

Presentaciones similares

Presentación del tema: "Tema 6: Concurrencia de Procesos"— 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 6: Concurrencia de Procesos

Presentaciones similares

Presentación del tema: "Tema 6: Concurrencia de Procesos"— Transcripción de la presentación:

Presentaciones similares

Sobre el proyecto

Feedback