sistemas operativos memoriamemoria gestión de procesos generalidades de s.o. generalidades de...
TRANSCRIPT
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).