Sistemas Operativos

MemoriaMemoria

Gestión deGestión deprocesosprocesos

GeneralidadesGeneralidadesde S.O.de S.O.

Generalidades de Sistemas Operativos is a Design Digital Content & Contents mall developed by Guild Design Inc.

Gestión de procesos is a Design Digital Content & ontents mall developed by Guild Design Inc.

Memoria Contents mall developed by Guild Design Inc.

Sistemas Operativos

ConceptosConceptosde Seguridadde Seguridad

DiscoDiscoDisco is a Design Digital Content & Contents mall developed by Guild Design Inc.

Conceptos de SeguridadContents 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

ListoEn ejecución

Bloqueado

Se despacha el proceso(se le da CPU)

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 cualestaba bloqueado

timeout

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

Listo

En ejecución

Bloqueado

Suspendido- Listo Suspendido-Bloqueado

Se bloquea a esperar por un evento

despachado

Ocurre evento

timeout

suspender

suspender

reanudarsuspender

reanudar

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):integerBegin

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/coendFact (n:integer):integerBegin

cobegina:=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 + yb:=z+1c:=a-bw:=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.)

a 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

S4

S6S5

fin

S3

33

Ejemplo

Es equivalente a:

Begininiccobegin

P1S3

coendfin

End

P1:

BeginS2S4cobegin

P5S6

coendEnd

34Ejemplo

Dado:inic

S2

S4

S6S5

fin

S3

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:=10Cobegin

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 usoComú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 1Procedure AliciaBegin

while true dowhile turno <> 1 do ;paseo_perro;turno:=2;hace_otras_tareas

endwhileEnd Alicia

46

Solución 1

Procedure BernardoBegin

while true dowhile turno <> 2 do ;paseo_perro;turno:=1;hace_otras_tareas

endwhileEnd Bernardo

47

Solución 1

Begin {main}turno:=1;cobegin

Alicia;Bernardo

coendEnd

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 2Procedure AliciaBegin

while true dowhile flag_b do ;flag_a:=true;paseo_perro;flag_a:=false;hace_otras_tareas

endwhileEnd Alicia

1234

5

54

Solución 2

Procedure BernardoBegin

while true dowhile flag_a do ;flag_b:=true;paseo_perro;flag_b:=false;hace_otras_tareas

endwhileEnd Bernardo

12345

55

Solución 2

Begin {main}flag_a:=false;flag_b:=false;cobegin

Alicia;Bernardo

coendEnd

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

1

2

1

3

2

4

3 4

FF FF TF TF FF

FF

FF

FT

FT FT

FT TT

TTTT

TT

FF

FF FF

FFTFTF

TF TF

FT

FT

AliciaB

ern

ard

o

RegiónCrítica

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 3Procedure AliciaBegin

while true doflag_a:=true;while flag_b do ;paseo_perro;flag_a:=false;hace_otras_tareas

endwhileEnd Alicia

61

Solución 3

Procedure BernardoBegin

while true doflag_b:=true;while flag_a do ;paseo_perro;flag_b:=false;hace_otras_tareas

endwhileEnd Bernardo

62

Solución 3

Begin {main}flag_a:=false;flag_b:=false;cobegin

Alicia;Bernardo

coendEnd

63

Comentarios

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

TT

64

Solución 4

Program Versión 4Procedure AliciaBegin

while true doflag_a:=true;while flag_b do

flag_a:=false;delay (random);flag_a:=true

endwhile;paseo_perro;flag_a:=false;hace_otras_tareas

endwhileEnd Alicia

65

Procedure BernardoBegin

while true doflag_b:=true;while flag_a do

flag_b:=false;delay

(random);flag_b:=true

endwhile;paseo_perro;flag_b:=false;hace_otras_tareas

endwhileEnd Bernardo

Solución 4

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 DekkerVar

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

coendEnd.

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;

p1_desea_entrar:=false;

otras_tareas_uno

endwhile

End proceso_uno

71

Algoritmo de DekkerProcedure proceso_dos;Begin

while true dop2_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

endifseccion_critica_2;proceso_favorecido:=primero;p2_desea_entrar:=false;otras_tareas_dos

endwhileEnd proceso_dos

72

Algoritmo de Peterson

Program petersonvar:

proceso_favorecido(primero, segundo);p1_desea_entrar, p2_desea_entrar: boolean;

FALTAN LOS PROCEDURESBegin {main}

p1_desea_entrar:=false;p2_desea_entrar:=false;proceso_favorecido:=primero;cobegin

proceso_uno;proceso_dos

coendEnd.

73

Algoritmo de Peterson

Procedure Proceso_unoBegin

while true dobegin 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

endWhileEnd Proceso_uno

74

Algoritmo de PetersonProcedure Proceso_dosBegin

while true dobegin 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

endWhileEnd 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 2x:=x + 3 x:=x + 10

LOAD XLOAD XREG =REG+3

REG=REG+10STORE X

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-1Else

wait on sEndif

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 ) thense despierta alguna en ellas

Elses:=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ónVar

s:semáforo;Procedure Alicia;Begin

while true doP(s);Paseo_perro;V(s);

endwhileEnd;

86

Continuación...

Procedure Bernardo;Begin

while true doP(s);Paseo_perro;V(s);

endwhileEnd;

87

Continuación...

Begin {main}init(s,1);cobegin

Alicia;Bernardo

coendEnd.

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: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:inic

S2

S4

S6S5

fin

S3

No se podía escribir con cobegin/coend

98

Continuación...

Primero se etiquetan las aristas “problemáticas” (donde hay bifurcaciones y donde se juntan).

inic

S2

S4

S6S5

fin

S3

a b

cd

e

f

g

99

Solución

Var a,b,c,d,e,f,g: semáforo;

Begininit(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

coendEnd.

104

Solución

Procedure Productor;Begin

while true doproduce;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 doP(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

TypeTbuffer=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

wrt,mutex:semaforo;read_cnt:integer;

Procedure reader;Procedure writer;Begin {main}

init(wrt,1);init(mutex,1);read_cnt:=0;

cobeginreader;reader; ......writer;writer;......

coendEnd.

112

Continuación...

Procedure readerBegin

P(mutex);read_cnt:=read_cnt+1;if read_cnt=1 then P(wrt);V(mutex);LEYENDO;P(mutex);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)

End;

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

Tenedor

F

F

F

FF

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)

coendEnd.

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]

endWhileEndFiló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)

coendEnd.

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 consumidorProgram Prod_Cons;Var

buffer:shared recordpool[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

coendEnd.

138

continuación

Procedure Produce;Begin

while true dodato:=obtener_dato();region buffer when (cont < N ) do

pool[in]:=dato;in:=(in+1) mod N;count:=count+1

endRegionendWhile

EndProduce;

139

continuación

Procedure Consume;Begin

while true doregion buffer when (cont > 0 ) do

dato_c:=pool[out]out:=(out+1) mod N;count:=count-1;consume(dato_c)

endRegionendWhile

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 waitingRegion 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 escritoresProgram lect_esc;Var

v:shared recordnlect,nescrit:integer;ocupado:boolean

end;ocupado:=false;nlect:=0;nescrit:=0

147

continuaciónProcedure lector; (MAS ADELANTE)Procedure escritor; (MAS ADELANTE)Begin{main}

ocupado:=false;nlect:=0;nescrit:=0;cobegin

lector;lector; ...escritor;escritor; ...

coendEnd.

148

Lector

Procedure lector;Begin

region v doawait(nescrit=0);nlect:=nlect+1

endRegion;leer;region v do

nlect:=nlect-1endRegion

EndLector;

149

Escritor

Procedure Escritor;Begin

region v donescrit:=nescrit+1;await(not(ocupado) and (nlect=0));ocupado:=true

endRegion;escribir;region v do

nescrit:=nescrit-1;ocupado:=false

endRegionEnd;

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).