Sistemas Operativos Generalidades de S.O. Gestión de procesos Memoria

Presentación del tema: "Sistemas Operativos Generalidades de S.O. Gestión de procesos Memoria"— Transcripción de la presentación:

1 Sistemas Operativos Generalidades de S.O. Gestión de procesos Memoria
Generalidades de Sistemas Operativos is a Design Digital Content & Contents mall developed by Guild Design Inc. Gestión de procesos Gestión de procesos is a Design Digital Content & ontents mall developed by Guild Design Inc. Memoria Memoria Contents mall developed by Guild Design Inc.

2 Conceptos de Seguridad
Sistemas Operativos Disco Disco is a Design Digital Content & Contents mall developed by Guild Design Inc. Conceptos de Seguridad Conceptos de Seguridad Contents mall developed by Guild Design Inc.

3 II - Gestión de procesos
Sistemas Operativos

4 Despachador de procesos
Es la parte del núcleo del SO que se encarga de administrar las tareas. También llamado despachador de tareas. Un proceso puede perder la CPU porque inicia una operación de E/S o porque expira su quantum de tiempo. Esta forma de reparto de CPU es la base de funcionamiento de los sistemas de tiempo compartido. Es posible manejar prioridades. Cada vez que se cambia de tarea en la CPU, hay que guardar el contexto.

5 Despachador de procesos
Una tarea que pierde la CPU queda marcada: Indicando que expiró su quantum de tiempo. O indicando que está esperando por alguna interrupción (por ejemplo una indicación de fin de impresión). Un sistema operativo monotarea y sin spooling, si tiene que imprimir, directamente puede mandar la información al buffer de la impresora. El compilador puede resolverlo. En un sistema operativo multitarea, si el compilador encuentra una impresión debe solicitar la impresión a través de la llamada al sistema correspondiente.

6 Proceso Es un programa en ejecución.
Un proceso es una entidad dinámica y un programa es una entidad estática. Varios procesos diferentes pueden ser instancias de un mismo programa. El sistema operativo guarda información de los procesos en una estructura de memoria llamada PCB (process control block). El PCB contiene, punteros al código, estado del proceso, punteros a recursos en uso, a recursos reservados, nivel de prioridad, etc.

7 Primer diagrama de estados
timeout En ejecución Se despacha el proceso (se le da CPU) Listo El proceso, en su ejecución, ejecuta una operación tal que queda esperando la ocurrencia de un evento (por ej. El fin de una operación de E/S). ocurre el evento por el cual estaba bloqueado Bloqueado

8 Operaciones sobre procesos
tiempo expirado : en ejecución a listo despachar : listo a en ejecución bloquear : en ejecución a bloqueado despertar : en ejecución a listo

9 Procesos El sistema operativo, en un momento dado, tiene un conjunto de procesos activos, que pueden estar en alguno de los estados anteriores. La cantidad de procesos “en ejecución” coincide con la cantidad de procesadores del sistema. De aquí en más suponemos que el sistema tiene un solo procesador. Un procesador “listo”, sólo espera la CPU para ser ejecutado.

10 Procesos En definitiva, los procesos en el sistema pueden verse como:
Un proceso utilizando la CPU Otros procesos en una “cola de listos”. Otros procesos en “cola de bloqueados” esperando la ocurrencia de ciertos eventos. Estas colas pueden ser también colas por prioridad.

11 El PCB Bloque de control del proceso o descriptor del proceso.
Define al proceso en el sistema operativo. Contiene información del proceso: Estado actual. Id del proceso en el sistema. Puntero al padre. Punteros a los procesos hijos. Prioridad del proceso. Punteros a las zonas de memoria asignadas al proceso. Punteros a los recursos asignados al proceso. Área para salvaguardar registros. SI hay más de una CPU, la CPU en la que se está ejecutando el proceso.

12 Operaciones sobre procesos
Crear (un proceso) Destruir Suspender Reanudar Cambiar prioridad Bloquear Despertar Despachar Establecer una comunicación entre procesos

13 Creación de procesos Implica:
Asignarle un nombre Crear su PCB Darlo de alta en la tabla de procesos del sistema Determinar su prioridad inicial Asignarle los recursos iniciales Todo proceso puede crear procesos hijos, existiendo entonces una estructura jerárquica que vincula los procesos del sistema.

14 El RCB Similarmente, el sistema operativo maneja los recursos a través de los Bloques de Control de Recursos.

15 Estados de suspensión Un proceso suspendido no puede continuar su ejecución a menos que sea reanudado por otro proceso. La suspensión puede ser usada para disminuir transitoriamente la carga del sistema. La reanudación es la operación que deja un proceso en el punto inmediatamente anterior a la suspensión. Se pueden suspender procesos por: falla inminente en el sistema, comportamiento errático o sospechoso de algún proceso, picos de carga en el sistema, etc.

16 Nuevo diagrama de estados
Bloqueado Listo Ocurre evento timeout Se bloquea a esperar por un evento despachado En ejecución reanudar suspender reanudar suspender suspender Suspendido- Listo Suspendido-Bloqueado Ocurre evento

17 Interrupciones Cuando ocurre una interrupción:
(una interrupción puede ser generada por el hardware o por otro proceso) El hardware pasa el control al sistema operativo El sistema operativo guarda el estado del proceso interrumpido, normalmente en el PCB El sistema analiza la interrupción y transfiere el control al handler (manejador) correspondiente. Normalmente se resuelve esto a nivel de hardware. Se ejecuta el handler Se restablece el estado del proceso interrumpido Se ejecuta el proceso interrumpido

18 Interrupciones Son una forma económica de llamar la atención a la CPU.
Así, la CPU no necesita escrutar los dispositivos para ver si alguno requiere atención. Recordar que normalmente los handlers se ejecutan con las interrupciones deshabilitadas. Tipos de interrupciones: de E/S, externas, de reinicio, de verificación de programa (anomalía en la ejecución), de verificación de la máquina (anomalía hardware).

19 El núcleo del SO Los procesos se controlan por el núcleo.
El núcleo es una parte pequeña del SO, pero es la más utilizada. Por lo general el núcleo reside en memoria principal, mientras que otras partes se cargan y descargan bajo demanda. El núcleo abarca la gestión de interrupciones. El núcleo deshabilita las interrupciones mientras ejecuta algún handler. Los handlers deben ser lo más breves y simples posibles por esa razón.

20 Funciones del núcleo Manejo de interrupciones
Creación y destrucción de procesos Cambio de estados entre procesos Despacho Suspensión y reanudación Sincronización de procesos Comunicación entre procesos Gestión de PCB Apoyo a actividades de E/S Asignación y liberación de memoria Gestión del file system Mecanismos para llamada y retorno desde procedimientos

21 Tendencias Partes del núcleo tienden a pasar al microcódigo de la CPU.
Con esto se gana en eficiencia y también en seguridad, ya que ejecuta en los modos privilegiados del procesador. También parte del núcleo tiende a aparecer embebida en el hardware de los controladores (caso típico es la lógica de manejo de disco).

22 Control de lectura A esta altura ya debe haber leído hasta el capítulo 3 (inclusive) de Deitel o su equivalente en los otros textos.

23 Concurrencia Es la posibilidad que varios procesos se ejecuten simultáneamente. Se denominan procesos concurrentes a aquellos que coexisten en un sistema. Los procesos concurrentes podrían ser ejecutados en paralelo en procesadores diferentes. PERO, en el caso más general habrá que repartir los procesadores del sistema entre los procesos en ejecución. Para simplificar, el problema es repartir el procesador entre los procesos en ejecución.

24 Un primer ejemplo Fact (n:integer):integer Begin
a:=semifact(1,piso(n/2)); b:=semifact(piso(n/2)+1,n); fact:=a*b End (ejercicio: hacer semifact(i,j), que calcula el producto de i a j).

25 Introduciendo cobegin/coend
Fact (n:integer):integer Begin cobegin a:=semifact(1,piso(n/2)); b:=semifact(piso(n/2)+1,n) coend; fact:=a*b End

26 Comentarios Al llegar a cobegin, se lanzan concurrentemente los cálculos e las variables a y b. En el coend se espera por el fin de ambos cálculos para continuar. En este caso realmente no se gana tiempo de CPU, pues no hay E/S, es todo cálculo y está el overhead por cambiar CPU entre procesos. De todos modos es un primer ejemplo de programación concurrente. Si hubiera más de un procesador, tal vez se ganara tiempo. Notar el programador no debe preocuparse por esto al crear el programa.

27 Otro problema Se quieren realizar los siguientes cálculos: a:=x + y
b:=z+1 c:=a-b w:=c+1

28 Otro problema No es posible lanzar concurrentemente las instrucciones anteriores debido a las precedencias. Sólo son asincrónicas (así se les llama) las dos primeras. El resto requiere de sincronización según cierto grafo de precedencias. Si no marcamos en el programa esa precedencia, todo queda librado a la suerte.

29 Grafo de precedencias Nodos: los procesos a ejecutar.
Aristas: existe arista entre v1 y v2 si y sólo si el proceso asociado al nodo v1 precede al proceso asociado al nodo v2. El grafo debe ser acíclico. El grafo de precedencias indica sin ambigüedades en qué orden es necesario ejecutar.

30 Ejemplo (anterior, cont.)
b c w

31 Dos herramientas Así, tenemos dos herramientas (tal vez con diferente poder expresivo) para describir concurrencia: Grafos de precedencia Cobegin/Coend

32 Ejemplo Dado: inic S2 S3 S4 S6 S5 fin

33 Ejemplo Es equivalente a: P1: Begin Begin inic S2 cobegin S4 P1
coend fin End P1: Begin S2 S4 cobegin P5 S6 coend End

34 Ejemplo Dado: inic S2 S3 S4 S6 S5 fin

35 Ejemplo No hay forma de describir el grafo anterior en términos de cobegin/coend. Es fácil demostrar que todo programa escrito por cobegin/coend puede describirse en términos de un grafo de precedencias. Entonces, el conjunto de situaciones de concurrencia descripto por cobegin/coend está estrictamente incluido en el conjunto de situaciones de concurrencia descripto por los grafos de precedencias. Una conclusión inmediata de lo anterior es que vamos a necesitar más herramientas, cobegin/coend no alcanzan.

36 Otro problema... Consideremos el programa:
J:=10 Cobegin print J; J:=1000 Coend ¿ Imprime 10 o imprime 1000 ? Depende del orden en que las operaciones lleguen a la CPU. Los programas concurrentes deberán ser independientes de dicho orden.

37 Características que se pedirán a los programas concurrentes
Consistencia: Los programas deberán ser consistentes en el sentido que NO deberán depender del orden en que se ejecuten las instrucciones concurrentes. Ausencia de deadlocks o puntos muertos: Se deben evitar situaciones en las que un conjunto de procesos quedan bloqueados “eternamente”, cada uno esperando por algún evento asociado a otro elemento del mismo conjunto. Ausencia de posposición indefinida: Habiendo varios procesos concurrentes, deberá cuidarse que algunos no acaparen la CPU en detrimento de otros.

38 Un problema típico El problema de la mutua exclusión.
Un recurso serialmente reusable (RSR) es un recurso que puede ser usado varias veces por distintos procesos, pero siempre uno por vez. Los procesos que quieren usar un recurso serialmente reusable deben esperar a que el mismo se encuentre libre. Por ejemplo una impresora, o una variable global. El problema de la mutua exclusión se da cuando dos o más procesos desean acceder concurrentemente a un recurso serialmente reusable.

39 Ejemplos Varios procesos que imprimen sobre la misma impresora.
Varios procesos que trabajan sobre los mismos saldos.

40 Solución “bruta” Si los procesos deben hacer cola por el RSR, entonces, anulamos la concurrencia, se ejecuta completamente uno y luego completamente el otro. Es una solución muy restrictiva, y estaríamos perdiendo la capacidad de modelar situaciones en las que varios procesos coexisten.

41 Alicia y Bernardo (A y B)
Es un problema de acceso bajo mutua exclusión. Es isomorfo a los problemas anteriores, pero permite ver con más claridad algunas situaciones.

42 El lugar Patio de uso Común. Casa de Alicia Casa de Bernardo

43 Reglas que definen el problema
Alicia vive en su casa. Bernardo vive en su casa. Los perros, como parte de su vida, cada tanto, necesitan “salir al patio”. Si los perros se encuentran en el patio, se pelean. Se desea programar procesos “Alicia” y “Bernardo” tales que puedan vivir cumpliendo las reglas anteriores.

44 Solución 1: Se usa un cartel que indica a quien le toca sacar al perro al patio. Cada uno pasea el perro (si es su nombre el que está en el cartel) y cambia el nombre para que el otro pueda pasear a su perro.

45 Solución 1 Program Versión 1 Procedure Alicia Begin while true do
while turno <> 1 do ; paseo_perro; turno:=2; hace_otras_tareas endwhile End Alicia

46 Solución 1 Procedure Bernardo Begin while true do
while turno <> 2 do ; paseo_perro; turno:=1; hace_otras_tareas endwhile End Bernardo

47 Solución 1 Begin {main} turno:=1; cobegin Alicia; Bernardo coend End

48 Detalles Alicia y Bernardo son los procesos.
El patio es el recurso a mutuo excluir. Notar que while true do hace un loop infinito. Notar que los procesos se coordinan (sincronizan) deteniéndose a esperar con while turno <> 1 do;

49 Un primer problema Busy Waiting: Los procesos que esperan no liberan la CPU, sino que como parte de su espera desperdician ciclos de reloj. Nos ocuparemos de este problema más adelante.

50 Problemas El cartel impone que Alicia y Bernardo se turnen.
No es posible que uno de los perros salga dos veces seguidas al patio. Si el perro que tiene el turno muere, el otro no puede salir más al patio.

51 Problemas Si un perro necesita ir muchas veces al
patio y otro pocas... entonces esta solución no es adecuada.

52 Solución 2 Alicia y Bernardo tienen cada uno una bandera.
Cuando uno saca al perro levanta su bandera. Antes de sacar al perro deben fijarse que la bandera del otro no esté puesta.

53 Solución 2 Program Versión 2 Procedure Alicia Begin while true do
while flag_b do ; flag_a:=true; paseo_perro; flag_a:=false; hace_otras_tareas endwhile End Alicia 1 2 3 4 5

54 Solución 2 Procedure Bernardo Begin while true do while flag_a do ;
flag_b:=true; paseo_perro; flag_b:=false; hace_otras_tareas endwhile End Bernardo 1 2 3 4 5

55 Solución 2 Begin {main} flag_a:=false; flag_b:=false; cobegin Alicia;
Bernardo coend End

56 Esta solución... No impone, como la solución anterior, restricciones sobre los paseos. Un perro puede salir todas las veces seguidas que quiera. Restan las preguntas: ¿Se resuelve el problema de la mutua exclusión? ¿Hay consistencia? ¿Hay deadlocks? ¿Hay aplazamiento indefinido? PARA ESTO SE UTILIZA LA METODOLOGÍA DE LOS ENTRELAZADOS.

57 Alicia 1 2 3 4 FF FF TF TF FF 1 TF FF FF TF FF 2 Bernardo FT FT TT TT FT 3 FT TT TT FT FT 4 Región Crítica FF TF TF FF FF

58 Comentarios sobre el diagrama
Detección de problemas con la mutua exclusión (intersección de regiones críticas). Detección de deadlocks. Detección de posposición indefinida. Granularidad de las operaciones indivisibles.

59 En este caso... Encontramos que hay casos en que se viola la exclusión mutua. Es el caso en que los dos “a la vez” intentan consultar la bandera del otro. Notar que “a la vez” significa que llegan consecutivas al procesador. No hay deadlocks ni posposición indefinida.

60 Solución 3 Program Versión 3 Procedure Alicia Begin while true do
flag_a:=true; while flag_b do ; paseo_perro; flag_a:=false; hace_otras_tareas endwhile End Alicia

61 Solución 3 Procedure Bernardo Begin while true do flag_b:=true;
while flag_a do ; paseo_perro; flag_b:=false; hace_otras_tareas endwhile End Bernardo

62 Solución 3 Begin {main} flag_a:=false; flag_b:=false; cobegin Alicia;
Bernardo coend End

63 Comentarios Esta solución tiene deadlock.
Probarlo por medio de los entrelazados. TT

64 Solución 4 Program Versión 4 Procedure Alicia Begin while true do
flag_a:=true; while flag_b do flag_a:=false; delay (random); flag_a:=true endwhile; paseo_perro; hace_otras_tareas endwhile End Alicia

65 Solución 4 Procedure Bernardo Begin while true do flag_b:=true;
while flag_a do flag_b:=false; delay (random); flag_b:=true endwhile; paseo_perro; hace_otras_tareas endwhile End Bernardo

66 Solución 4 Begin {main} flag_a:=false; flag_b:=false; cobegin Alicia;
Bernardo coend End

67 Comentarios No se eliminan completamente el problema del deadlock y de la posposición indefinida. Con probabilidad baja pero podrían ocurrir.

68 Algoritmo de Dekker Es el que soluciona el problema.
Utiliza un cartel y dos banderas. Persiste el problema de Busy Waiting. El algoritmo de Peterson también resuelve el problema, con busy waiting, pero es un poco más simple.

69 Algoritmo de Dekker Program Dekker Var
proceso_favorecido: (primero, segundo); p1_desea_entrar, p2_desea_entrar: boolean; FALTAN PROCEDURES Begin {main} p1_desea_entrar:=false; p2_desea_entrar:=false; proceso_favorecido:=primero; cobegin proceso_uno; proceso_dos coend End.

70 Algoritmo de Dekker Procedure proceso_uno; Begin while true do
p1_desea_entrar:=true; while p2_desea_entrar do if proceso_favorecido=segundo then p1_desea_entrar:=false; while proceso_favorecido= segundo do; p1_desea_entrar:=true endif seccion_critica_1; proceso_favorecido:=segundo; otras_tareas_uno endwhile End proceso_uno

71 Algoritmo de Dekker Procedure proceso_dos; Begin while true do
p2_desea_entrar:=true; while p1_desea_entrar do if proceso_favorecido=primero then p2_desea_entrar:=false; while proceso_favorecido= primero do; p2_desea_entrar:=true endif seccion_critica_2; proceso_favorecido:=primero; otras_tareas_dos endwhile End proceso_dos

72 Algoritmo de Peterson Program peterson var:
proceso_favorecido(primero, segundo); p1_desea_entrar, p2_desea_entrar: boolean; FALTAN LOS PROCEDURES Begin {main} p1_desea_entrar:=false; p2_desea_entrar:=false; proceso_favorecido:=primero; cobegin proceso_uno; proceso_dos coend End.

73 Algoritmo de Peterson Procedure Proceso_uno Begin while true do begin
p1deseaentrar:=true; proceso_favorecido:=segundo; while p2_desea_entrar and proceso_favorecido = segundo do; sección_crítica_1; p1_desea_entrar:=false; otras_taeras_uno endWhile End Proceso_uno

74 Algoritmo de Peterson Procedure Proceso_dos Begin while true do begin
p2deseaentrar:=true; proceso_favorecido:=primero; while p1_desea_entrar and proceso_favorecido = primero do; sección_crítica_2; p2_desea_entrar:=false; otras_taeras_dos endWhile End Proceso_dos

75 Hasta aquí Tenemos algoritmos para resolver el problema de la mutua exclusión: Persiste el problema de Busy Waiting Las soluciones logradas no son fáciles de generalizar: A n procesos. A n recursos.

76 Un detalle El patio podría ser por ejemplo una variable global.
En todo momento hay que decidir la granularidad de las operaciones a ser realizadas en forma atómica por la CPU. En los ejemplos anteriores la granularidad venía dada como que cada instrucción del pseudoPascal usado era atómica, es decir, no se podía perder el procesador durante su ejecución. Pero podría trabajarse a nivel de Assembler, es decir, con la posibilidad de perder CPU a nivel de una instrucción de Assembler.

77 Un detalle Proceso 1 Proceso 2 x:=x + 3 x:=x + 10 LOAD X REG =REG+3
STORE X

78 Un detalle Como se ve, pueden aparecer los mismos problemas de intercalamiento de operaciones a este nivel. Pero también aparece (no está reflejado ahí) el hecho de salvar el contexto al quitar la CPU a un proceso.

79 Se necesitan otras herramientas
Con los semáforos: Se trabajará con primitivas bloqueantes, eliminando así el problema del busy waiting. Se lograrán soluciones que pueden generalizarse con mayor facilidad.

80 Semáforos Son un TAD, inventado por Dijkstra.
Utiliza el estado “bloqueado”, por lo tanto no hay busy waiting. s:Semáforo, s pertenece a N init(s, v) Inicializa la variable s con el valor v. Sólo se puede usar una vez, y es cuando se crea el semáforo. P(s) Operación WAIT. V(s) Operación SIGNAL.

81 Semáforos P(s) If s > 0 then s:=s-1 Else wait on s Endif wait on S, significa que se bloquea hasta que el evento asociado a S lo despierte. El proceso que hace P(s) queda en estado bloqueado, entonces no usa la CPU. No hay busy waiting.

82 Semáforos V(s) If (existe tarea esperando en s ) then
se despierta alguna en ellas Else s:=s+1 Endif Se despierta alguna tarea que se bloqueó haciendo P(s). Al elegir alguna implementación concreta se determinará el orden en que se van despertando las tareas bloqueadas. De acuerdo al TAD, se despierta una cualquiera.

83 Comentarios P y V son operaciones que deben ejecutarse en forma INDIVISIBLE. No es posible interrumpir su ejecución. Las soluciones que usan semáforos no deben presuponer que las tareas bloqueadas por P, son despertadas por V en algún orden particular.

84 Otra implementación alternativa
init(s,v) P(S): s:=s-1; if s<0 then wait V(S): s:=s+1; if s<=0 then despertar_alguna_tarea

85 Problema de A y B implementado con semáforos.
Program Mutua_Exclusión Var s:semáforo; Procedure Alicia; Begin while true do P(s); Paseo_perro; V(s); endwhile End;

86 Continuación... Procedure Bernardo; Begin while true do P(s);
Paseo_perro; V(s); endwhile End;

87 Continuación... Begin {main} init(s,1); cobegin Alicia; Bernardo coend

88 Comentarios Notar como la operación P de Alicia es desbloqueada por la operación V de Bernardo y viceversa. No hay busy waiting. Si son varias Alicia o varios Bernardo la generalización es inmediata. El semáforo se asocia al recurso a mutuo excluir: el patio. Se cumple la siguiente propiedad (invariante): s vale 0 sii algún proceso está ejecutando en la región crítica. (1a implem).

89 Comentarios Si se quiere generalizar a más patios, hay que proteger cada patio con un semáforo, y discutir algunos detalles más de cómo se comparten. La idea es que se pone un semáforo por cada recurso a mutuo excluir. Si a algún proceso le falta el V(s) puede quedar algún proceso bloqueado eternamente...

90 Una variante del problema
Si queremos que de n procesos, sólo k (k<n) entren a la vez a la región crítica, entonces basta cambiar: Init (s,k) En lugar de init (s,1). Ejercicio: reformular el invariante para este caso.

91 Varios problemas 3 personas, 1 patio, 1 por vez en el patio: 1 semáforo valiendo 0 o 1. 3 personas, 1 patio, no más de 2 en el patio: 1 semáforo con valores 0, 1 o 2. (Para eso Init en 2). 100 personas, 3 patios, no más de 2 por patio: 3 semáforos con {0,1,2}.

92 Un caso problemático Si un proceso hace: Y otro proceso hace: P(Q)
V(S) Y otro proceso hace: P(S) V(Q) Si al principio S y Q están en 0, puede haber deadlock.

93 Implementación con busy waiting
(se implementan de forma atómica) P(s): While s <=0 do ; s:=s-1 V(s): s:=s+1 Init(s,k): s:=k

94 Implementaciones menos problemáticas
Normalmente se implementan con llamadas al despachador de tareas, usando los cambios de estados asociados a las situaciones de bloqueo. También existen implementaciones basadas en “test_and_set”, etc.

95 Desventajas de los semáforos
No son útiles en procesos concurrentes en distintos sistemas dentro de una misma red (donde es costosísimo e inconveniente trabajar con variables globales). Los semáforos son variables globales y tienen las dificultades de manejo que tienen estas.

96 Semáforos binarios Sus valores son 0 y 1.
Si está en 0 y hay un signal, entonces queda en 1. Si está en 1 y hay un signal, entonces queda en 1. Son más fáciles de implementar y a partir de ellos se pueden implementar los generales (haciendo que las operaciones indivisibles sean protegidas con un semáforo binario).

97 Retomando el problema de los grafos de precedencia
Dado: No se podía escribir con cobegin/coend inic S2 S3 S4 S6 S5 fin

98 Continuación... Primero se etiquetan las aristas “problemáticas” (donde hay bifurcaciones y donde se juntan). inic a b S2 S3 e S4 c d S6 S5 g fin f

99 Solución Var a,b,c,d,e,f,g: semáforo; Begin init(a,0); init(b,0);
init(g,0)

100 Solución Cobegin; begin S1;V(a);V(b);end;
begin P(a); S2; S4; V(c);V(d);end; begin P(b); S3; V(e); end; begin P(c); S5; V(f); end; begin P(d); P(e); S6; V(g); end; begin P(f); P(g); S7; end Coend;

101 Comentarios Notar como dentro de cada una de las líneas del cobegin/coend hay ejecución secuencial (de izda. a derecha). Los semáforos se inicializan en 0, por lo tanto todas las P bloquean. Son las V las que van destrancando ordenadamente. En definitiva, con cobegin/coend y semáforos se logra el mismo poder expresivo que con los grafos de precedencia.

102 Problema del Productor-Consumidor
El productor coloca datos en un buffer. El consumidor toma datos del buffer. Deben hacerlo en forma sincronizada pues: Al buffer hay que acceder bajo mutua exclusión. El productor no puede seguir colocando en un buffer lleno. El consumidor no puede tomar de un buffer vacío.

103 Solución Program Productor_Consumidor; Var n,e,s: semáforo;
Procedure Productor; Procedure Consumidor; Begin {Main} init(s,1); init(n,0); init(e,tamaño+/-1) cobegin productor; consumidor coend End.

104 Solución Procedure Productor; Begin while true do produce;
P(e); {para que no produzca si lleno} P(s); {mut exc} Agrega_buffer; V(s); V(n); {Avisa que si estaba vacío ya no lo está} endWhile End

105 Solución Procedure Consumidor; Begin while true do
P(n); {por si está vacío hay que bloq.} P(s); {mut exc} Toma_Buffer; V(s); V(e); {Avisa que si estaba lleno ya no lo está} endWhile End;

106 Comentarios Semáforo s: se usa para la mutua exclusión al acceder al buffer. Semáforo n: Evita que se extraiga de un buffer vacío. Semáforo e: Evita que se coloque en un buffer lleno. Los semáforos n y e son usados, como se ve, para sincronización.

107 Ejercicio Implementar la solución anterior con todo detalle.
El buffer se puede implementar mediante un array circular: Un array y dos punteros sobre el array.

108 Observación Type Tbuffer=record datos:array[0..N] of T;
próximo_a_insertar, próximo_a_leer, cant_elems:0..N end; Var buffer:Tbuffer

109 Generalización Es inmediata, no requiere cambios.
Podrían lanzarse en el cobegin/coend varios Productores y varios Consumidores.

110 Problema de los lectores y escritores
Un conjunto de lectores y escritores acceden a un área en común. Cualquier cantidad de lectores pueden acceder simultáneamente al área común. Dos escritores no pueden acceder simultáneamente. Si un escritor está en el área, tampoco pueden acceder lectores a la misma.

111 Solución Program lect_escr; Var cobegin wrt,mutex:semaforo; reader;
read_cnt:integer; Procedure reader; Procedure writer; Begin {main} init(wrt,1); init(mutex,1); read_cnt:=0; cobegin reader; ...... writer; coend End.

112 Continuación... Procedure reader Begin P(mutex); read_cnt:=read_cnt+1;
if read_cnt=1 then P(wrt); V(mutex); LEYENDO; read_cnt:=read_cnt-1; if read_cnt=0 then V(wrt); V(mutex) End;

113 Continuación... Procedure writer; Begin P(wrt); ESCRIBIENDO; V(wrt)

114 Comentarios El semáforo mutex se usa para el manejo bajo mutua exclusión de la variable read_cnt. El primer lector es quien bloquea con el semáforo wrt. El último lector avisa al semáforo wrt que es el último (operación V). Notar que puede haber varios lectores y varios escritores ejecutando concurrentemente. Este algoritmo da prioridad a los lectores sobre los escritores.

115 Problema de los filósofos
5 filósofos se sientan a la mesa. Su vida (de acuerdo al ejercicio) consiste en pensar y comer, pensar y comer, etc. Para comer requieren dos tenedores. Pero hay sólo 5 tenedores, dispuestos a la izquierda de cada filósofo. Los filósofos se sientan a una mesa circular, según se muestra en el esquema. Se debe programar los filósofos, buscando que todos puedan comer.

116 Problema de los filósofos
Plato F Tenedor F F

117 Primera solución Program Filósofos; Var
tenedor:array[0..4] of semáforo; Procedure Filósofo(i:integer); (más adelante) Begin {main} for i:=0 to 4 do init (tenedor[i],1); cobegin filosofo(0); ... filosofo(4) coend End.

118 continuación Procedure Filósofo(i:integer); Var izq,der:integer; Begin
izq:=i; der:=(i+1) mod 5; while true do pensar; P(tenedor[izq]); P(tenedor[der]); comer; V(tenedor[der]; V(tenedor[izq] endWhile EndFilósofo;

119 Problemas Una secuencia de acciones problemática, ocurre cuando todos los filósofos “a la vez” hacen P(izq). En ese caso todos quedan bloqueados, esperando por el filósofo a su derecha. Entonces, esa solución no sirve pues tiene deadlock.

120 Solución No se permite a los 5 filósofos estar sentados a la mesa a la vez. La cantidad de filósofos en el comedor se restringe a 4.

121 Implementación de la solución
Program FilósofosV2; Var tenedor:array[0..4] of semáforo; comedor:semáforo; Procedure Filósofo(i:integer); (más adelante) Begin {main} for i:=0 to 4 do init (tenedor[i],1); init(comedor,4); {no deja pasar más de 4 al comedor} cobegin filosofo(0); ... filosofo(4) coend End.

122 continuación Procedure Filósofo(i:integer); Var izq,der:integer; Begin
izq:=i; der:=(i+1) mod 5; while true do pensar; P(comedor); P(tenedor[izq]); P(tenedor[der]); comer; V(tenedor[der]; V(tenedor[izq]; V(comedor) endWhile EndFilósofo;

123 Observación De acuerdo a las operaciones del TAD semáforo, no hay forma de consultar el valor del semáforo. O sea, NO hay una operación status. Esto implica que al hacer una operación wait (P) no es posible saber antes si ese wait bloqueará. Sin embargo, es usual encontrarla en las implementaciones de semáforos que proveen los sistemas operativos o los lenguajes de programación.

124 Una variante: semáforos bibloqueantes
Un proceso puede quedar bloqueado al hacer wait (P) (como en los semáforos comunes), pero también al hacer signal (V) sobre el valor máximo. Init queda igual. P queda igual. V(s) signal sobre el valor máximo (que es con el que se inicializa el semáforo) queda también bloqueado.

125 Semáforos en Unix En Unix System V se trabaja con arrays de semáforos.
Operaciones: id=semget(key,count,flag) Crea un semáforo. En id devuelve el identificador del semáforo. El nombre del semáforo es key, count da el largo máximo del array de semáforos, flag permite manejar distintas variantes. val_viejo=semop(id,oplist,count) id es el semáforo a operar, oplist es un array con valores y count dice cuantos de esos valores se consideran. Se suman los valores del array oplist al array del semáforo. Si algún semáforo da 0, el proceso que hizo semop se bloquea.

126 Continuación... Basta dar largo 1 para tener el caso estudiado (semáforos de Dijkstra). semctl(id,nro,cmd,arg) Setea el semáforo, id identifica al array de semáforos sobre el que opera, nro es el número a configurar en todos los elementos del array, cmd y arg permiten comandos y argumentos específicos.

127 Críticas a los semáforos
El problema es que si olvido un P o un V la solución se tranca. O sea, si bien es un TAD, deja abiertas muchas alternativas para usarlos mal. Se recurre entonces a primitivas de más alto nivel, que no dejen abiertas estas posibilidades de usos problemáticos. Entre ellas, las critical regions, los monitores y los rendez_vous de Ada son casos tópicos que veremos.

128 Control de lectura A esta altura ya debe haber leído hasta el capítulo 4 (inclusive) de Deitel o su equivalente en los otros textos.

129 Regiones críticas v: shared t v es una variable compartida de tipo t
Region v do S; Define una región de mutua exclusión sobre la variable v.

130 continuación Region v do S1 Y Region v do S2
Se ejecutan bajo mutua exclusión.

131 continuación El compilador, por cada: Region v do S Genera: P(SV); S;
V(SV)

132 Un caso problemático Region t do Region v do S3
Region v do Region t do S4 Si se ejecutan concurrentemente, puede ocurrir deadlock.

133 Más críticas Estas primitivas no tienen el mismo poder expresivo que los semáforos. Por ejemplo el problema de los filósofos no puede resolverse con esta herramienta.

134 Diferencias con semáforos
Los semáforos son herramientas de más bajo nivel que las critical regions. Normalmente los semáforos se manejan a nivel del SO. Normalmente las critical regions se manejan a nivel del LP.

135 Conditional critical regions
Son una alternativa a las CR, con mayor poder expresivo. Region V when B do S Sólo si B es verdadera entra en la CR. Si B no es verdadera, se bloquea a esperar que lo sea.

136 Problema del productor consumidor
Program Prod_Cons; Var buffer:shared record pool[0..n-1] of item; count, in,out:integer:=0 end; Procedure Produce; (MAS ADELANTE) Procedure Consume;(MAS ADELANTE)

137 continuación Begin{main} cobegin produce; consume coend End.

138 continuación Procedure Produce; Begin while true do
dato:=obtener_dato(); region buffer when (cont < N ) do pool[in]:=dato; in:=(in+1) mod N; count:=count+1 endRegion endWhile EndProduce;

139 continuación Procedure Consume; Begin while true do
region buffer when (cont > 0 ) do dato_c:=pool[out] out:=(out+1) mod N; count:=count-1; consume(dato_c) endRegion endWhile EndProduce;

140 Comentarios Al poner regiones críticas se logra acceder al buffer bajo mutua exclusión. Con el when en productor se evita que se inserte en un buffer lleno. Con el when en consumidor se evita que se tomen datos del buffer vacío.

141 Detalle importante Los procesos que se bloquean por la región crítica LO HACEN FUERA DE LA MISMA. Por ejemplo si el consumidor está esperando en la CR a que el buffer no esté vacío, lo hace fuera de la misma y de ese modo el productor podrá en algún momento colocar algún valor en el buffer. Para entrar a la región crítica hay que: Satisfacer las condiciones en el When. No debe haber otro proceso dentro de la CR.

142 Implementación con semáforos y busy waiting
Region V when B do S Se implementa como: While not B do ; P(SV); S; V(SV)

143 Equivalencia Las CCR tienen el mismo poder expresivo que los semáforos. Es posible implementar semáforos con CCR. Es posible implementar CCR con semáforos.

144 Otra variante para CCR Region v do begin S1; await(B); S2 end
Await(B) hace que el proceso se bloquee a esperar asociado a la región crítica. O sea, se bloquea y libera la CR, y cuando me señalan, indicando que se cumple B, ejecuta S2.

145 continuación Siempre luego de un await se retoma desde donde estaba.

146 Problema de los lectores y escritores
Program lect_esc; Var v:shared record nlect,nescrit:integer; ocupado:boolean end; ocupado:=false; nlect:=0; nescrit:=0

147 continuación Procedure lector; (MAS ADELANTE)
Procedure escritor; (MAS ADELANTE) Begin{main} ocupado:=false; nlect:=0; nescrit:=0; cobegin lector; lector; ... escritor; escritor; ... coend End.

148 Lector Procedure lector; Begin region v do await(nescrit=0);
nlect:=nlect+1 endRegion; leer; nlect:=nlect-1 endRegion EndLector;

149 Escritor Procedure Escritor; Begin region v do nescrit:=nescrit+1;
await(not(ocupado) and (nlect=0)); ocupado:=true endRegion; escribir; nescrit:=nescrit-1; ocupado:=false endRegion End;

150 Comentario await(C) Es equivalente a:
Esperar hasta que ocurra C y ceder la región crítica.

151 Críticas Tanto en regiones críticas como en regiones críticas condicionales se necesitan variables globales para la sincronización. Las variables globales restan claridad, dificultan el mantenimiento de la solución. Las variables globales complican la generalización de procesos concurrentes en una máquina a procesos concurrentes que intercambian datos a través de la red. Surgen los monitores, con el fin de evitar estos problemas (1974).