resumen concurrencia y sincronización de procesos

Vista previa del material en texto

Resumen de la actividad concurrente y sincronización de procesos
1. Para mejorar la eficiencia (rendimiento) de los sistemas de computación se decide compartir los recursos tanto de hardware como de software.
2. La compartición se hará entre los procesos/hilos que necesiten esos recursos.
3. La multiprogramación es la característica que ofrecen algunos sistemas operativos que permiten compartir entre los procesos/hilos una UNICA CPU.
4. Se conoce como concurrencia a la ejecución entrelazada o simultánea de instrucciones de diferentes procesos o hilos en un mismo sistema.
5. La concurrencia será lógica, si los procesos/hilos, se alternan en el uso de una única cpu.
6. La concurrencia será física, cuando haya un proceso/hilo por cpu.
7. Existen tres modelos de computador en los que se puede ejecutar procesos concurrentes:
a. Multiprogramación con un único procesador. El sistema operativo reparte el tiempo del procesador entre los distintos procesos, intercalando la ejecución de los mismos para dar así una apariencia de ejecución simultánea.
b. Multiprocesador o máquina formada por un conjunto de procesadores que comparten el acceso a una memoria principal común. Se suelen denominar arquitecturas fuertemente acopladas, los procesos concurrentes no sólo pueden intercalar su ejecución sino también superponerla
c. Multicomputador o máquina de memoria distribuida en la que los nodos se encuentran conectados y se comunican entre sí a través de una red de interconexión, empleando el método de paso de mensajes. En este tipo de arquitecturas es posible la ejecución simultánea de los procesos sobre los diferentes procesadores.
8. La concurrencia puede presentarse en tres contextos de programación diferentes:
a. Múltiples aplicaciones: la multiprogramación se creó para permitir que el tiempo de procesador de la máquina fuese compartido dinámicamente entre varias aplicaciones activas.
b. Aplicaciones estructuradas: algunas aplicaciones pueden implementarse eficazmente como un conjunto de procesos concurrentes.
c. Estructura del sistema operativo: los diseñadores de sistemas operativos aplican estas ventajas de estructuración en los sistemas operativos que se implementan como procesos o hilos concurrentes.
9. Tanto para concurrencia lógica como la física, los problemas que se plantean son similares.
10. Para coordinar la ejecución de los procesos es necesario que se cuente con herramientas o mecanismos que logren frenarlos (hacerlos esperar activamente) o bloquearlos, cuando no convenga el acceso simultáneo a los recursos (recursos de uso exclusivo) o haya que respetar un orden de ejecución
11. Las actividades de los procesos pueden ser independientes o cooperativas.
12. Se dice que un proceso es independiente cuando resuelve sólo, una aplicación o problema. En ese caso habrá que cuidar que los procesos de este tipo lleguen ordenadamente (exclusión mutua) a los recursos de uso exclusivo. Es decir, estos procesos sólo son competitivos. Ejemplos:
a. Cuando dos procesos intentan acceder al disco, el sistema operativo deberá encargarse de que accedan ordenadamente uno por uno (el problema no está en el brazo mecánico: serial, sino en las memorias caché que se anteponen para ganar rendimiento)
b. Cuando varios procesos desean modificar el contenido de un registro de una base de datos, es el gestor de la base de datos es el que se encargará de ordenar los distintos accesos al registro.
13. Los procesos serán cooperativos cuando haya varios de ellos resolviendo una aplicación o problema. Esos querrán comunicarse y sincronizarse para alcanzar un objetivo común. En este caso además de cuidar la exclusión mutua en el intento de acceso simultáneo a los recursos, será necesario que coordinen o sincronicen de acuerdo a las condiciones que imponga el problema a resolver. Entonces el comportamiento de estos procesos llevará a que haya que resolver:
a. La competencia entre los procesos
b. La comunicación entre los procesos
c. La sincronización entre los procesos
Ejemplo: los procesos de tipo productor y consumidor.
14. La coordinación en el acceso a los recursos puede ser:
a. Implícita: la provee el sistema operativo de forma transparente sin que un proceso deba preocuparse. Por ejemplo, por las direcciones de memoria asignada.
b. Explícita: este es el tipo de coordinación que necesitan los procesos cooperativos. Acá los procesos son conscientes del uso de recursos compartidos. Es necesario que utilicen mecanismos de sincronización y comunicación proporcionados por el sistema operativo o por el lenguaje de programación.
15. En el mundo del software denominamos sincronización de procesos/hilos a la posibilidad de impedir el progreso de ejecución de algún/algunos procesos a favor de otros. La sincronización puede hacerse en los distintos niveles del computador:
a. Las aplicaciones: en el lenguaje mismo. Por ejemplo Java y C# ofrecen mecanismos para el acceso coordinado a los recursos compartidos. En cambio C y C++ no soportan la sincronización ni la concurrencia.
b. Biblioteca de tiempo de ejecución del lenguaje o en las funciones de API, es decir las aplicaciones pueden llamar a funciones en nivel de usuario para ayudarse en la coordinación. Estas funciones podrán implementar ahí mismo la solución.
c. Sistema operativo: mediante funciones de biblioteca, se podrá hacer llamadas al sistema para que el kernel proteja o coordine en bajo nivel las actividades de los procesos/hilos.
d. Hardware: Los programadores le llaman “hardware” a las instrucciones especiales que la CPU (en el nivel ISA) puede ofrecer para ayudar a la sincronización (por ejemplo: Deshabilitar interrupciones, hacer lectura/modificación/escritura en una sola instrucción: Test&Set, Switch, etc)
16. Las principales dificultades para aprovechar eficientemente la concurrencia en las aplicaciones son:
a. Las tecnologías de software no han avanzado en ningún conjunto de paradigmas aplicables a la programación general para los programas concurrentes. Cada solución para programación concurrente necesita de un nuevo enfoque y diseño.
b. La sincronización se localiza en el corazón de cualquier implementación de programación concurrente. Los sistemas operativos proporcionan sólo el mecanismo mínimo para soportar la sincronización y la concurrencia.
17. Problemas que plantea la concurrencia:
a. Condiciones de carrera: surge cuando varios procesos acceden de forma concurrente y sin coordinación a recursos compartidos. Donde dos o más procesos están leyendo o escribiendo algunos datos compartidos y el resultado final depende de quién se ejecuta y exactamente cuando lo hace. Para evitar que se produzcan condiciones de carrera, las instrucciones que operan sobre recursos de uso exclusivo deben ejecutarse en exclusión mutua o de forma atómica, es decir de forma completa e indivisible.
b. Condiciones de sincronización: a veces la solución de problemas impone un “orden de ejecución”, que debe cumplirse (esto ocurre con procesos cooperativos)
c. El cuidado de ambas condiciones (carrera y sincronización) puede ocasionar 2 problemas:
i. Inanición: se denomina al efecto negativo que se ocasiona a un proceso, esto ocurre cuando un proceso no puede acceder a un RECURSO necesario para el PROGRESO del proceso. Se dice también que la ausencia de recurso genera el bloqueo del proceso.
ii. Interbloqueos (Dead Lock): supone un bloqueo permanente de un conjunto de procesos encadenados (en el sentido P1RiP2Rj……P1
18. Modelo de acceso a una sección crítica: Dijkstra, estudió el problema de la Exclusión Mutua y lo enfocó o enmarcó de la siguiente manera: “cada proceso tiene un segmento de código llamado sección crítica, en el que modifica variables comunes, actualiza una tabla, escriben un archivo, etc”. Es decir toma un recurso de uso exclusivo. La característica importante es que cuando un proceso está ejecutando su sección crítica, ningún otro proceso puede ejecutar su correspondiente sección crítica. Para resolver el problema asociado a una sección crítica es necesario utilizar algún mecanismode sincronización que permita a los procesos cooperar entre ellos sin problemas. El mecanismo que deben seguir los procesos que deseen ingresar a la sección crítica de código, deberán cumplir:
a. Cada proceso debe solicitar permiso para entrar en la sección crítica. Estas instrucciones son llamadas la entrada en la sección crítica. Si algún proceso se está ejecutando ya dentro de la sección crítica, este código de entrada para que el proceso que desea entrar espere.
b. Cuando un proceso sale de la sección crítica, debe liberarla e indicar mediante otro fragmento de código llamado salida de la sección crítica. Sí hubiera algún proceso esperando, este código le permitirá el ingreso.
Cualquier solución que se utilice para resolver este problema debe cumplir con al menos 3 requisitos:
1. Exclusión mutua: sólo un proceso por vez puede ingresar a la sección crítica.
2. Progreso: si no hay ningún proceso en la sección crítica, los procesos que no desean ingresar no deben interferir en la decisión de cuál ha de entrar de los que están esperando.
3. Espera limitada (Inanición): debe ponerse límite a los procesos que ingresan repetidas veces a sección crítica, si es que ya hubiera algún otro proceso que haya hecho una solicitud de ingreso.
Soluciones al problema de la sección crítica usando memoria compatida:
19. Solución por software: 
Para Procesos: Tanto para 2 o N procesos, éstos deben hacer llamadas al sistema para permitir compartir memoria (ya sea páginas o segmentos), donde usarán variables que servirán para sincronizar (todos los procesos tendrán acceso a esas variables). 
Ventajas: * Rapidez (no participa el kernel, sólo inicialmente para compartir memoria)
Desventajas: 1) los recursos a proteger en la sección crítica, son estructuras de datos a nivel de usuario. 2) todos los procesos que deseen acceder a sección crítica, deben conocer la solución (Ponerse de acuerdo entre los usuarios/programadores), esto es complicado 3) Tiene espera activa (NOP) 4) No tiene buen rendimiento (se ejecutan muchas instrucciones para la sincronización)
Para hilos de un mismo proceso: ventajas: Rapidez, No participa el kernel. Desventajas: idem a procesos.
20. Solución por Hardware: Como el problema era la protección de la Sección crítica. No dejar que se ejecutara ninguna de las instrucciones de otro proceso/hilo que lo haga dentro de la sección crítica ocupada. 2 variantes:
a. Deshabilitar las interrupciones (Entrada) y Habilitarlas (Salida): ventajas: simple. Desventajas: 1) El SO no puede atender los eventos que se atienden a través de la ejecución de las rutinas de interrupción 2) Peligroso para que el usuario la use, porque puede entrar en un lazo infinito (obviamente a través de llamadas al sistema) 3) puede llevar a inanición 4) no sirve para SMP
do { 
		Disabled()
			critical section 
		Enabled()
			remainder section 
	} while (TRUE); 
b. Ejecutar instrucciones especiales, que hagan lectura/modificación/escritura en una sola instrucción: Por ejemplo: Test&Set, Swap, Exchange, etc. Ventajas: 1) es simple 2) puede ejecutarse sin intervención del kernel (estas instrucciones corren en modo usuario) 3) Sirve para SMP. Desventajas: 1) Tiene espera activa 2) Si se usa en aplicaciones de usuario, una mala programación, puede llevar a inanición.
function test&set (X:boolean) : boolean;
	begin 
				test&set = X;
				X = false;
	end 
	Solución con test&set()
			boolean X = true;
	do forever 
				while not test&set(X) do nop; 
					<Sci>
				X = true;
	end 
21. Semáforos:
Es un mecanismo de sincronización que se utilizan en sistemas con memoria compartida, bien sea monoprocesador o multiprocesador (deben estar protegidos por Test&Set u otra instrucción que inhiba el ingreso al bus de direcciones cuando una CPU está accediendo a una posición de memoria). Está bien decir que es un tipo abstracto de datos. 
Se conoce a Edsger Dijkstra como el inventor del semáforo. Fue la primera primitiva software en conseguir la sincronización de procesos. El artículo de Dijkstra consiguió lo siguiente:
· Presentar la idea de cooperación entre procesos secuenciales.
· Ilustrar la dificultad para conseguir la sincronización utilizando únicamente instrucciones de máquina.
· Postuló las primitivas.
· Demostró que funcionaban.
· Proporciona un buen número de ejemplos.
En su primer trabajo, presentó al semáforo (por ej. S) como una variable entera no negativa, que contenía el número de habilitaciones que se guardaba en esta variable especial. Era modificada o comprobada sólo por una de las tres rutinas de acceso indivisible:
1) Inicialización: aquí se le fija el valor entero inicial
2) Operación signal o V(S): [S=S+1]
3) Operación wait o P(S):[While(S==0) {esperar}; S=S-1]
Los corchetes rodeando las sentencias en las rutinas de acceso indican que las operaciones son indivisibles o atómicas.
La operación P, dice que si S es mayor que 0, se comprueba y decrementa en una operación indivisible. Sin embargo, si S es igual a cero, el proceso ejecutando la operación P puede ser interrumpido cuando ejecuta la orden esperar en el bucle while. La indivisibilidad se aplica sólo el test y el control de flujo posterior, no en el tiempo en el que el proceso espera porque S es igual a cero.
La operación P se emplea para comprobar de manera indivisible una variable entera y para bloquear el proceso invocador si la variable no es positiva.
La operación V lanza indivisiblemente una señal a un proceso bloqueado para permitirle que reanude su funcionamiento.
La nomenclatura P y V puede aparecer como wait y signal respectivamente (se consideran indistintamente)
Hay que reconocer que Dijkstra pensó que los sistemas operativos debían contar con el apoyo de procesos cooperativos, es decir que ayuden a la sincronización (enviando un V o signal cuando sea necesario despertar a otro). Los procesos hacen llamadas al sistema para solicitar sincronizarse:
Operación P o wait:
· Preguntar si pueden acceder a Sección crítica: porción de código que hace uso de un recurso compartido pero no-compartible simultáneamente. 
· Preguntar si se dan las condiciones de sincronización (de acuerdo al problema) para seguir ejecutando.
Operación V o signal:
· Señalizar (a un proceso que espera por un recurso o a uno que puede venir a tomarlo) y liberar un recurso reutilizable o generar un recurso consumible (tipo mensaje) para que otro proceso lo pueda usar.
Semáforos binarios:
Denominó semáforo binarios aquellos cuya variable entera puede sólo tomar los valores cero y uno. Los pudo implementar con operaciones de CPU (test&Set) en modo usuario, de la siguiente manera, por ej:
Una operación Pb (P sobre un semáforo binario Sb), podría simularse:
While not Test&Set(Sb) do NOP
Donde Sb sería equivalente a una variable semáforo entera con valores posibles 1 y 0, pero en realidad es booleana (el 0 sería False y el 1 sería True), porque Test&Set() opera sobre dato booleano. Si Sb es True, entonces el proceso que ejecute primero la Test&Set, le regresará True, por lo que no tendrá espera activa con NOP (pasa el protocolo de entrada de la sección crítica), pero deja a la variable Sb en falso. Cualquier otro proceso que ejecute el while posteriormente encontrará la variable Sb en falso, devolverá falso Test&Set y se quedará ejecutando NOP (espera activa) todo el tiempo que le toque ejecutar.
Una operación Vb (P sobre un semáforo binario Sb), podría simularse:
Sb = True
Es equivalente al uso de Test&Set para proteger la sección crítica
Uso de semáforo para resolver el problema de la sección crítica
Se solicita la creación de una variable tipo semáforo (al compilador, luego éste prepara el código de llamada o no al sistema).
El Valor inicial del semáforo es 1, por lo general lo llaman Mutex (por su función)
Cuando un proceso está listo para entrar en su sección crítica, aplica la operación P sobre Mutex. El primer proceso en invocar P sobre Mutex pasa y el segundo se bloquea.
Cuando el primero invoca V sobre Mutex, continúa su ejecución, haciendo que el segundo pueda proceder cuando tomecontrol de la cpu.
P(Mutex)
<sección crítica>
V(Mutex)
El problema básico de sincronización (en una situación sencilla de condiciones de sincronización)
El proceso a debe escribir en X, luego b, debe leerlo. Por último b, debe escribir en Y y luego a debe leerlo.
Se resuelve estas condiciones de sincronización con 2 semáforos: S1 y S2. Las operaciones P y V obligan a sincronizarse.
Proceso a
<escribir (X)>
V(S1)
<computar>
P(S2)
<leer (y)>
Proceso b
P(S1)
<leer (X)>
<Computar>
<escribir(Y)>
V(S2)
El problema del buffer limitado (Productor/consumidor)
Se definen 3 semáforos: s, para exclusión mutua; e y f para condiciones de sincronización
 (
V
) (
P
) (
V
) (
V
) (
V
)Procesos Productores
 (
Semáforo s
) (
P
) (
P
)
 (
1
)
 (
Semáforo e
)
 (
n
)
 (
Buffer
)
semaforo	e = n; {número de celdas vacías}
semaforo	f = 0; {número de celdas llenas}
semaforo	s = 1; {utilizado para exclusión mutua }
Productor: 
	do forever 
	 <producir el próximo registro>
	 P(e); {decrementa valor de celdas vacías 
		 {o espera si no hay vacía}
	 P(s); {se está por ingresar a la sección crítica}
	 <SECCION CRITICA: agregar registro al buffer>
	 V(s); {se salió de la sección crítica}
	 V(f); {incrementa # celdas llenas y despierta}
		 {consumidor esperando por celda llena}
	end do
 (
Procesos Consumido
res
)
 (
P
)
 (
Semáforo f
) (
0
)
Consumidor: 
	do forever 
	 P(f); {decrementa valor de celdas llenas o }
		 {espera si no hay llena}
	 P(s); {se está por ingresar a la sección crítica}
	 < SECCION CRITICA: quitar registro del buffer>
	 V(s); {se salió de la sección crítica}
	 V(e); {incrementa # celdas vacías y despierta}
		 {product. esperando por celda vacía}
	 <procesar registro extraído>
	end do 
Existen o se han inventado otros problemas de sincronización: Lectores/Escritores, Filósofos cenando, de la Peluquería, etc. En cada uno de los escenarios habrá que identificar cuáles son los recursos de uso exclusivo (para cuidar la exclusión mutua) y cuáles son las condiciones de sincronización del problema. Si se han de resolver con semáforos: a) proteger la entrada a sección crítica con operación P, avisar en la salida con operación V. b) preguntar con operaciones P si están dadas las condiciones de sincronización y señalizar o avisar si el proceso cumple con la condición que otro esperaba.
Los semáforos inventados por Dijkstra, tienen 2 tipos de implementaciones:
a) Con espera activa: la espera que se hace si el valor del semáforo no permite completar la operación P o wait, se la lleva a cabo, ejecutando instrucciones de CPU (como NOP o alguna otra, sin avanzar en la computación). Entonces la variable entera semáforo podría ser accedida (simulando atomicidad) por una operación P o wait que se puede construir con operación Test&Set, por ej, de la siguiente manera:
semaforo mutex = true; {semaforo binario} 
semaforo delay = false; {semaforo binario}
Operación P(S):
Pb(mutex);
	S = S - 1;
	if S < 0 then 
		Vb(mutex);
		Pb(delay);
Vb(mutex);
Operación V(S):
Pb(mutex);
	S = S + 1;
	if S =< 0 then Vb(delay);
else Vb(mutex); 
Las operaciones Vb y Pb pueden ser implementadas de la siguiente forma:
Vb(Sb):	Sb = true 
Pb(Sb):	while not test&set(Sb) do nop 
Lo que vemos, es lo útil que resultaron ser los semáforos binarios. Ya que para cumplir con la atomicidad de las operaciones P y V sobre semáforos generales (como en este caso P(S) o V(S)), no fue necesario hacer atómico a todas las instrucciones de la primitiva, sino a aquellas partes donde se modificaban o consultaban la variable compartida S; esto para el Kernel es muy bueno, porque al no deshabilitar las interrupciones, puede atender eventos, durante la ejecución de las operaciones P(S) y V(S). Esto se logró con la simulación de semáforo binario mutex y la operación Pb(mutex), que solo deja pasar a un proceso por vez (el que detectó mutex en true), que protegía la resta y suma de la variable S. Esto tiene además, la ventaja que los semáforos con espera activa podrían implementarse en espacio de usuario (con la ayuda del compilador o de una función de biblioteca de usuario), pero por supuesto cuidando siempre que el semáforo se comporte como un tipo abstracto de datos. 
A estos semáforos, no les hace falta cola de espera, ya que tienen espera activa (esperan en CPU y en cola ready)
b) Sin espera activa o con bloqueo: En este tipo de implementación, debe participar el Kernel, porque es el único que puede bloquear procesos o hilos (ingresar a la tabla de procesos/hilos y cambiarles el estado). Ahora los semáforos, además de variable entera semáforo, primitivas que operan sobre ella, deberán contar con colas de espera para los procesos que no puedan completar con las operaciones P o wait. 
P(s):
s = s - 1;
if s < 0 { cambio de proceso }
	insertar proceso en cola de procesos bloqueados en s;
bloquear el proceso;
end
V(s): 
s = s + 1;
if s <= 0
	sacar un proceso de cola de procesos bloqueados en s;
desbloquear el proceso; {cambiar de estado} 
end 
En ambas implementaciones, ya se nota que la variable semáforo, puede tomar valores negativos, cuestión no prevista originalmente por Dijkstra (porque el semáforo guardaría cantidad de señales y no uno no se imagina cantidad de señales negativas). Luego de esta curiosidad, se les encuentra sentido a los valores negativos de los semáforos: es la cantidad de procesos bloqueados en cola de espera. Mientras que los valores positivos, hablan de la cantidad de operaciones P o wait que se pueden hacer, sin bloquearse.
Ventajas del uso de semáforos: 
a) Es una herramienta muy flexible creada para sincronizar procesos/hilos, se pueden ubicar las operaciones P y V, en donde el programador considere necesario.
b) Al ser un tipo abstracto de datos, ya están especificados los procedimientos que trabajarán sobre la variable protegida semáforo.
c) Al poder implementarla en el sistema operativo, los programadores se desentienden de la validez o ámbito que cubre el semáforo (todos los procesos/hilos pueden solicitar operar sobre éstos). Los semáforos podrían representar a cualquier recurso que el sistema operativo quiera proteger.
Desventajas del uso de semáforos: 
a) La ventaja a) se torna en una gran desventaja, porque, sin estructuras un programador puede cometer muchos errores. Es como programar en bajo nivel, solo que peor que programar en lenguaje ensamblador. La ausencia o exceso de operaciones P y V, pueden llevar a errores impredecibles. No hay que olvidarse que a los recursos públicos compartidos, los tratará de usar cualquier programador (mal intencionado o NO)
b) Pueden olvidarse de incluir operaciones P y V para proteger secciones críticas (se viola la Exclusión Mutua)
c) No se restringen las operaciones sobre los recursos: se puede leer o escribir tantas veces como uno quiera (los procedimientos sólo cuidan la exclusión mutua de la variable semáforo)
d) No hay distinción en la protección a la exclusión mutua o en fijar las condiciones de sincronización (para ambos casos se usan operaciones P y V).
e) El mantenimiento de los programas que usan semáforos es muy difícil de mantener, porque los códigos de sincronización están repartidos por todo el programa.
f) Si no se establece un orden (Dijkstra no dijo nada sobre eso), a través del cual los procesos son liberados (uno por uno) cuando completan la operación P, es posible que algunos caigan en inanición, al no ser elegidos.
22. Monitores:
Hoare (1974) se dio cuenta de las desventajas de los semáforos e inventó un mecanismo de abstracción de datos, que le llamó monitor y que consistía en:
· Un conjunto de datos a proteger
· Procedimientos que pueden exportarse para que cualquier proceso pueda llamarlo y ejecutarlo uno por uno
· Variables condición: que posibilitan que el programador fije sus condiciones de sincronización y haga esperar en colas de condición (tantas como variables de condición haya) a los procesos que se les niegue proseguir, porque simplemente las condiciones no está dadas para continuar.
Nota: comopuede existir, si no se prevé en los procedimientos, la posibilidad de que ejecuten 2 procesos en un monitor: el proceso que ejecute el procedimiento que despierta a otro (el que ejecuta una operación signal) y el que es despertado de una cola condición, hay que priorizar uno de los dos: el despertado o el despertador. Seguimos la idea original de Hoare: que siga el despertado (que tiene que aprovechar que la condición se cumple ahora) y el despertador esperará en una cola privilegiada (llamada cola urgente).
Los monitores ofrecen las siguientes ventajas:
a) Se ha separado la cuestión de la exclusión mutua (el monitor la ofrece naturalmente, sin que se la pida) de las condiciones de sincronización (se las hace cumplir con variables condición).
b) Sólo un procedimiento por vez puede ejecutarse dentro del monitor (garantiza la Exclusión Mutua). Esto lo puede hacer, debido a que existen mecanismos del kernel que son llamados implícitamente, cuando comienza cada procedimiento, por ejemplo se trata de una operación P sobre un semáforo binario o de un cerrojo, ambos con colas de bloqueo asociadas, donde los procesos quedarán bloqueados, si ya hay otro proceso que ejecuta un procedimiento del monitor. Luego los procedimientos emiten una señal (con operación V) o liberan el cerrojo, permitiendo que un nuevo proceso ingrese al monitor cuando ejecuta otro procedimiento.
c) En los procedimientos habrá que ejecutar operaciones wait sobre una variable condición, de manera que expulsen a los procesos “activos”, cuando no estén dadas las condiciones y tendrán que esperar en las colas de condición. Luego otro proceso, ejecutando un procedimiento con signal sobre esa variable, hará que reingrese el proceso activo en el punto que pidió la expulsión y el que lo llamó con el signal, deberá retirarse temporalmente a una cola urgente o de cortesía (volverá a ingresar apenas el otro proceso se vaya nuevamente del monitor). En realidad wait y signal son 2 llamadas al sistema explícitas (da la pauta que no se resuelve o no se implementa el monitor si no fuera por el kernel que asegura que los procesos son bloqueados en colas especiales: una por cada condición). 
d) Son soluciones de alto nivel (es un servicio que se lo llama, no hay que estar programando cada vez que se accede a un recurso compartido), en el sentido que están implementados por procesos pasivos (para distinguir que hay procesos activos: los que quieren resolver un problema en particular o de una aplicación y llamarán a los procesos pasivos, cada vez que necesiten acceder a los recursos que los monitores protegen).Ningún proceso está encargado de la administración del recurso, sino que hay como una función de biblioteca (la del lenguaje que implementa el monitor: Pascal concurrente, Java, etc.) que cualquier proceso puede ejecutar. Esto despreocupa a los programadores, que podrían abocarse a la resolución del problema de la aplicación. Esto también significa que ningún proceso puede hacer cualquier cosa con el recurso, sino lo que se ha establecido en los procedimientos que se ejecutan dentro del monitor.
e) Todas las colas de procesos bloqueados (la principal para tomar el monitor, las de condición o la urgente o de cortesía) funcionan como FCFS, así que en principio, los monitores no llevan a inanición.
23. Mecanismos ofrecidos por los sistemas operativos:
a. Solaris:
i. Semáforos
ii. Mutex que se adaptan
1. Con espera activa
2. Con bloqueo
iii. Variables condición
iv. Cerrojos tipo lector/escritor
v. Colas de bloqueo
b. Windows:
i. Para hilos que estén ejecutando en el kernel (prueba de que son monolíticos):
1. Monoprocesador: Enmascara las interrupciones
2. Multiprocesador: Cerrojos con espera activa
ii. Para hilos que estén en modo usuario, ofrece objetos despachadores
1. Semáforos
2. Mutex
3. Sucesos
4. Temporizadores
c. Linux:
i. Para hilos que estén ejecutando en el kernel (prueba de que son monolíticos):
1. Monoprocesador: desactiva la característica de kernel apropiativo
2. Multiprocesador: bucles sin fin (con espera activa) para secciones críticas cortas
ii. Para hilos que estén ejecutando en modo usuario, se ofrecen llamadas al sistema:
1. Monoprocesador: desactivan y activan la característica de kernel apropiativo
2. Multiprocesador: semáforos para secciones críticas largas
2.33Silberschatz, Galvin and Gagne ©2009Operating System Concepts –8
th
Edition
Espacio de los Procesos de UsuariosHARDWARE
SOFTWARE
Llamadas al Sistema
Set de Instrucciones del Procesador
Instrucciones usuarioInstrucciones Privilegiadas
Test&Set, Switch, etcDisabled, Mask, etcHalt, cambiar bits de PSW, etc
ModoPrivilegiado
ModoUsuario
Rutinas de las llamadas al sistema
Solución por Software: Memoria común entre los procesos de UsuariosProceso 1Proceso 2Biblioteca o API de funciones: Ofrece Servicios en Modo Usuario o llama al Kernel(ingresa al Kernel)Ejecución de Compilador de un lenguajePrograma fuentePrograma Objeto con Servicio de: Mutexes, Semáforos, Monitores, etcProcesoImplementación de Mutex, Semáforos, Pipes, etc, en nivel del Sistema Operativo
Sistema Operativo
Espacio de los Procesos de Usuarios
HARDWARE
SOFTWARE
Llamadas al Sistema
Set de Instrucciones del Procesador
Instrucciones usuario
Instrucciones Privilegiadas
Test&Set, Switch, etc
Disabled, Mask, etc
Halt, cambiar bits de PSW, etc
Modo
 Privilegiado
Modo
 Usuario
Rutinas de las llamadas al sistema
Solución por Software: Memoria común entre los procesos de Usuarios
Proceso 1
Proceso 2
Biblioteca o API de funciones: Ofrece Servicios en Modo Usuario o llama al Kernel (ingresa al Kernel)
Ejecución de Compilador de un lenguaje
Programa fuente
Programa Objeto con Servicio de: Mutexes, Semáforos, Monitores, etc
Proceso
Solución por Hardware: 
Implementación de Mutex, Semáforos, Pipes, etc, en nivel del Sistema Operativo
Sistema Operativo
2.‹Nº›
Silberschatz, Galvin and Gagne ©2009
Operating System Concepts – 8th Edition
33
6.14Silberschatz, Galvin and Gagne ©2009Operating System Concepts –8
th
Edition
Solución para 2 procesos: Algoritmo de Peterson (1981)
booleanC1=C2=true;intturno;
P
1
:repeatforeverC1=falseturno=1while(C2=false)and(turno=1)donop{Zona2}
<SC1>C1=true;programa1:{Zona1}enddoP
2
:repeatforever
C2=falseturno=2while(C1=false)and(turno=2)donop{Zona2}
<SC2>
C2=true;programa2:{Zona1}
enddo
Zona 3Zona 3
Solución para 2 procesos: Algoritmo de Peterson (1981)
boolean C1 = C2 = true; int turno; 
P1:
	repeat forever
		C1 = false
		turno = 1
		while (C2 = false) and (turno = 1) do nop {Zona 2}
			<SC1>
		C1 = true; programa1: {Zona 1}
	 end do
P2:
	repeat forever
		C2 = false
		turno = 2
		while (C1=false) and (turno = 2) do nop {Zona 2}			<SC2>
		C2 = true; programa2: {Zona 1}
	end do
Zona 3
Zona 3
6.‹Nº›
Silberschatz, Galvin and Gagne ©2009
Operating System Concepts – 8th Edition