Clase 1 Java

Sistemas Operativos II
Contenido Curso
 Módulo 1: Concurrencia
 Módulo 2: Interbloqueo
 Módulo 3: Sistemas Operativos de Tiempo Real
 Módulo 4: Sistemas de Múltiples Procesadores
 Módulo 5: Seguridad
1
Sistemas Operativos II
Módulo 1
CONCURRENCIA
2
Temas a desarrollarse
 Principios de la Concurrencia
 Exclusión Mutua
- Soporte de software
- Soporte de hardware
 Sistemas Distribuidos
 Sincronización
- Basada en Mensajes
- Invocación a Procesos Remotos - RPC -
3
Introducción
 Los SO´s modernos se diseñan a partir de los conceptos de

procesos e hilos (threads).
En relación a éstos (procesos e hilos) están asociados los
temas de:
 Multiprogramación: El SO administra múltiples procesos o
hilos en un sistema monoprocesador.
 Multiprocesamiento: El SO administra múltiples procesos o
hilos en un sistema multiprocesador.
 Procesamiento Distribuido: Los SO´s administran múltiples
procesos o hilos que corren en varios computadores
interconectados por una red de comunicación.
4
Introducción
Al haber múltiples procesos o hilos ejecutando en cualquiera de
los entornos mencionados se dice que hay CONCURRENCIA DE
PRCESOS.
La concurrencia de procesos implica interacción entre los
procesos. Esta interacción, a su vez, implica que el SO debe
intervenir en (¿qué?):
 La comunicación entre procesos.
 El compartimiento de - o competencia por - recursos.
(El SO debe proveer a los procesos un acceso ordenado a los
recursos de uso exclusivo).
 La sincronización de actividades de múltiples procesos.
 La asignación de tiempo de procesador a los procesos.
5
Introducción
La concurrencia puede aparecer en 3 contextos diferentes:
(¿dónde?)
 Múltiples aplicaciones. La multiprogramación o multitarea
fue ideada para permitir compartir dinámicamente el tiempo
de procesamiento entre varias aplicaciones activas. (contexto
más común).
 Aplicaciones estructuradas. Como extensión del principio
de diseño modular y programación estructurada, algunas
aplicaciones pueden ser programadas - a fin de lograr mayor
eficiencia en la ejecución - como un conjunto de procesos
concurrentes.
 Estructura del SO. En el diseño de los SO (como un
conjunto de procesos o hilos) también se aplican las mismas
ventajas usadas en la construcción de aplicaciones
6
estructuradas.
Introducción
La concurrencia no sólo se presenta en sistemas
multiprocesador y distribuidos, también está en los sistemas
multiprograma con monoprocesador.
La diferencia fundamental está en que, desde el punto de vista de
la ejecución de los procesos:
• En sistemas con un único procesador la concurrencia o
paralelismo entre los procesos es lógica.
• En cambio en los sistemas con más de un procesador o en
sistemas distribuidos, la concurrencia o paralelismo es física.
7
Interacción entre Procesos
• Durante su vida los procesos del sistema junto con los
procesos de los usuarios interactúan entre sí compartiendo
recursos, y también compitiendo por el uso de esos recursos.
• Por este motivo, respecto de los recursos, los procesos son
cooperativos - cuando comparten - y competitivos - cuando
compiten -.
COMPETENCIA
• Uno de los problemas que se presenta en el diseño de SO´s es
cuando dos o más procesos compiten por un recurso que no
puede ser compartido en forma simultánea. Ej: dos procesos
necesitan modificar el mismo registro de una base de datos.
• Los procesos que intervienen en este caso se denominan
procesos competitivos. 8
COOPERACIÓN
 Una situación diferente aparece cuando dos o más procesos
cooperan en resolver un mismo problema.
 En este caso cada proceso conoce la existencia de los otros y
por lo tanto debe sincronizarse su ejecución con el resto de
los procesos con lo cuales coopera.
 Los procesos que intervienen en este tipo de tareas se
denominan procesos cooperativos.
 Un ejemplo típico lo constituyen los procesos del tipo
productor/consumidor -ver figura siguiente-.
9
Productor Producir Buffer Consumir Consumidor
EJEMPLO DE PROCESOS COOPERATIVOS

El proceso productor genera (produce) bloques de datos que
son depositados en el buffer, los cuales son extraídos
(consumidos) del buffer por el proceso consumidor.
Este tipo de tareas aparecen en diversas situaciones en los
SO´s, por Ej: 1) Un proceso de impresión y el driver de la
impresora. 2) Un proceso compilador produce un código en
assembler que es consumido por el proceso ensamblador el
que, a su vez, genera el código de máquina que es
consumido por el proceso loader, que carga dicho programa
10
en la memoria principal del sistema.
COOPERACIÓN (cont)
Importante: Cuando ejecutan procesos cooperativos, el SO debe
proveer sincronización entre los mismos.
Esto es debido a que los procesos productor y consumidor se
ejecutan de forma concurrente y, posiblemente, a diferentes
velocidades.
Para sincronizar los procesos cooperativos, el SO provee
primitivas de sincronización que evitan, por ejemplo, que el
proceso productor no sobreescriba datos en el buffer antes que
el proceso consumidor los haya retirado (leído).
11
CLASIFICACIÓN GENERAL DE INTERACCIÓN
Según la interacción entre los procesos habrá competencia o
cooperación. Se pueden tener los siguientes tipos de
interacción:
 Procesos independientes entre sí: en este caso los procesos
no conocen la existencia de otros procesos.
Esta situación es la que se presenta con mayor frecuencia en
los sistemas multiprogramados con el acceso a recursos de
uso exclusivo: un disco, una impresora, un registro de archivo.
(independientemente del número de procesadores que
contenga el sistema).
El sistema debe arbitrar los medios para que la competencia
de acceso a tales recursos sea de manera secuencial (no
12
simultánea).
 Procesos indirectamente dependientes entre sí: los
procesos no conocen la existencia de otros procesos en forma
explícita pero comparten algún objeto en común como, por
ejemplo, un buffer de E/S. (Ej: un proceso de impresión con el
driver de la impresora).
En este caso se presenta una cooperación entre procesos en
el compartimiento del recurso.
 Procesos directamente dependientes entre sí: son procesos
que se comunican entre sí por el ID y trabajan en forma
conjunta, cooperándose mutuamente en alguna actividad.
Estos procesos son cooperativos.
13
Grado de Influencia de un proceso
Relación
dependencia sobre otro
Procesos Competencia. Los resultados de un proceso son
independientes. independientes de la acción de otros.
La velocidad de ejecución puede
verse afectada.
Procesos Cooperación por Los resultados de un proceso pueden

indirectamente compartimiento. depender de la información provista
por otros.
dependientes
verse afectada.
Procesos Cooperación por Los resultados de un proceso pueden

directamente comunicación. depender de la información provista
por otros.
dependientes.
verse afectada. 14
Grado de
Relación Problemas y soluciones
dependencia
Debe proveerse a los procesos

Procesos
Competencia exclusión mutua
independientes.
evitando interbloqueo e inanición.
Debe proveerse a los procesos

Procesos
Cooperación por exclusión mutua y sincronización
indirectamente
compartimiento. evitando interbloqueo, inanición y
dependientes.
corrupción de los datos.
Procesos Debe proveerse a los procesos

Cooperación por
directamente sincronización
comunicación.
dependientes. evitando interbloqueo e inanición
15
Problemas potenciales derivados de la concurrencia, o sea,
de la interacción entre procesos:
 Inanición de procesos: ya fue tratado en SO-I
 Exclusión Mutua: será abarcado en el presente módulo 1.
 Interbloqueo: se estudiará en el módulo 2.
16
Problema de la Sección Crítica
 El problema de la sección crítica nace de la competencia de
los procesos por el acceso a recursos de uso compartido.
 Cuando varios procesos pueden aleatoriamente modificar el
contenido de un recurso que es compartido entre ellos, el SO
debe proveer mecanismos para proteger al recurso del acceso
simultáneo de dos o más procesos a fin de evitar la posible
corrupción de los datos.
 Este tipo de recursos compartidos se dice que son de uso
exclusivo y pueden ser lógicos (software) o físicos (hardware).
 Recursos exclusivos lógicos: archivo, estructura de datos,
variable compartida.
 Recursos exclusivos físicos: discos, impresoras, placas de
red. 17
Introducción del problema de la sección crítica:
Supóngase que 2 procesos P1 y P2 están ejecutando
concurrentemente y deben incrementar una variable x
compartida[*] entre ambos. x: puede ser, p/ej. el nº de archivos
abiertos, o el nº de procesos terminados del sistema, etc.
P1: . P2: .
. .
x=x+1 x = x +1
Estas instrucciones en lenguaje de alto nivel son traducidas en
varias instrucciones en código de máquina.
[*]No confundir variable compartida con variable global.
Var. compartida: puede ser accedida por todos los proc´s. que la referencian.
Var. global: es accedida sólo por los proced´s o rutinas de dicho proceso).
Una var. compartida es definida en un espacio de direcciones universal, 18
mientras que una var.global es definida en el espacio de direcciones del procso.
• Para simplificar el ejemplo considérese un computador con dos
procesadores centrales C1 y C2, cada uno con sus registros
internos R1 y R2.
• Si C1 procesa a P1 y C2 procesa a P2 se podrían tener los
siguientes casos de secuencia de ejecución de estos procesos
en lenguaje de máquina:
19
Caso 1:
P1: R1 = x P2: ...
R1 = R1 + 1 ...
x = R1 ...
R2 = x
R2 = R2 + 1
x = R2
Caso 2:
P1: R1 = x P2: ...
R1 = R1 + 1 …………………….. R2 = x
x = R1 …………………….. R2 = R2 + 1
x = R2
P/Ej: si inicialmente x = 2, en Caso1, x = 4; en cambio, en Caso2,
20
x=3
Análisis del ejemplo anterior:
Del Caso1 y Caso2 se observa que se obtienen resultados
diferentes en el valor de x que dependen del instante en que
comenzaron a ejecutarse los procesos P1 y P2, lo cual es
totalmente inaceptable.
Para obtener la solución correcta (x = 4), en el ejemplo visto se
debería permitir que sólo un proceso por vez incremente la
variable x.
Esto implica que la sentencia x = x +1 es una sección crítica del
programa, debiéndose evitar que dos procesos ingresen a la
misma simultáneamente.
Dicho de otra forma: sólo se debe permitir que los procesos
ingresen en forma mutuamente excluyente a la misma.
Debe proveerse exclusión mutua de los procesos en la sección
crítica. Con ello se evita la corrupción de la información. 21
ESCENARIO GENERAL
Se analizará el problema de la sección crítica en forma genérica:
Existen varios procesos secuenciales cíclicos que, generalmente,
se comunican a través de una o más variables compartidas.
Cada proceso tiene una sección crítica durante la cual accede a
un dado recurso compartido de uso exclusivo.
Para un dado recurso compartido de uso exclusivo:
 El objetivo es lograr que en cualquier momento sólo uno de los
procesos se encuentre procesando en su sección crítica.
 Es lo mismo que decir: una vez que un dado proceso se
encuentra ejecutando en su sección crítica, ningún otro
proceso puede ejecutar en su correspondiente sección crítica
22
(Exclusión mutua).
Esquemáticamente, el modelo que se propone para analizar el
problema es el sigte: (se trata de un único recurso)
P1: P2: ... Pn:

do forever do forever do forever
< SC1 > < SC2 > < SCn >
programa1 programa2 programan
end do end do end do
Por ejemplo, supóngase que hay n aplicaciones (P1, P2, … Pn)

que pueden hacer uso de una impresora; si P2 se encuentra en
su SC2 (imprimiendo), ningún otro proceso puede estar en su
correspondiente SC hasta tanto P2 no haya salido de su SC2.
23
La solución al problema de garantizar la exclusión mutua de
varios procesos respecto de un recurso compartido, no
solamente debería cumplir con la condición de acceso
exclusivo de uno de ellos a su SC, sino con otras condiciones
que impidan, por ejemplo:
 la inanición de uno o más procesos
 el bloqueo indefinido de uno o más procesos.
En concreto: lo que se debe cuidar es que la solución que
garantice la exclusión mutua entre procesos no genere
inanición o bloqueo indefinido en otros procesos.
Atento a lo dicho, se verá ahora cuáles son las condiciones que
debe cumplir la solución propuesta para el acceso de los
procesos a un recurso compartido de uso exclusivo.
24
CONDICIONES QUE DEBE CUMPLIR LA SOLUCIÓN DE LA SC.
1. Los procesos P1, P2, … Pn no pueden estar simultáneamente
en sus secciones críticas (exclusión mutua).
2. Un proceso que esté fuera de su SC - ni siquiera intentando
ingresar a su SC - no puede evitar que otro proceso entre a su
SC.
3. No puede ser posible que un proceso ingrese a su SC en
repetidas oportunidades y que otro proceso nunca tenga la
posibilidad de ingresar a su SC (inanición).
4. Dos o más procesos que están por ingresar a sus respectivas
SC no pueden entrar en un lazo de espera infinito (bloqueo
indefinido).
25
Soluciones al Problema de la Sección Crítica
SOLUCIÓN POR SOFTWARE
Solución para el caso de 2 procesos respecto de un recurso.
Objetivo: En base al diagrama esquemático de los procesos que
se muestra en la figura, la solución implica diseñar el código
Comienzo_SC y Fin_SC que cumpla con las 4 condiciones
enunciadas.
Comienzo_SC Comienzo_SC
< SC1 > < SC2 >
Fin_SC Fin_SC
Programa1 Programa2
... ...
Proceso P1 Proceso P2 26
SOLUCIÓN POR SOFTWARE (Cont.)
La solución del problema, aunque parezca simple, es de suma
complejidad y llevó varios años encontrar un resultado que
cumpla con la 4 condiciones establecidas.
A continuación se verán algunos ejemplos que, a primera vista,
serían una solución al problema; pero que, cuando se los
analiza con detenimiento, se advierte que no cumplen con una
o más condiciones impuestas. Esto permitirá reconocer la
complejidad del problema.
27
SOLUCIÓN POR SOFTWARE - Ejemplo 1
Objetivo: se intentará lograr que los procesos P1 y P2 entren a su
respectivas SC alternadamente; para ello se usará la variable
compartida turno que mantiene el turno del proceso al que
corresponde ingresar a su SC:
int turno = 2; (corresponde ingresar a P2)
P1: P2:
do forever do forever
while turno = 2 do nop; while turno = 1 do nop;
< SC1 > < SC2 >
turno = 2; turno = 1;
programa1; programa2;
end do end do 28
SOLUCIÓN POR SOFTWARE - Ejemplo 1 (cont)
La solución propuesta falla en la condición 2. En efecto, si por
ejemplo el programa1 fuese mucho más largo que el
programa2 (o se ejecuta en un procesador más lento) o si el
proceso P1 se bloqueara en el programa1; el proceso P1, que
se encuentra totalmente fuera de SC1, estaría bloqueando el
ingreso de P2 a SC2.
Eso es debido a que cuando P1 está en programa1, el valor de
turno podría ser 1[*] y, por lo tanto, P2 no puede ingresar a SC2.
[*] Esto ocurre si estando P1 en su programa1, P2 ingresa a su

SC y al salir pone turno = 1.
29
Se sigue con los 2 procesos.
Objetivo: para evitar el problema de la solución propuesta en el
Ejemplo1 se utilizarán dos variables comunes C1 y C2 que
indicarán si un proceso está dentro o fuera de su SC.
Descripción de la operación:
Proceso Pi desea entrar en su SCi: para ello pone el indicador Ci
en “falso” y espera que el otro indicador esté en “cierto” para
entrar en su SCi. Luego que sale de su SCi y pone el
indicador Ci en “cierto” permitiendo que el otro proceso
pueda ingresar a su SC.
30
SOLUCIÓN POR SOFTWARE - Ejemplo 2 (cont.)
Boolean C1 = C2 = true; {valor inicial de variables compartidas}
P1: P2:
C1 = false; C2 = false;
while not C2 do nop; while not C1 do nop;
< SC1 > < SC2 >
C1 = true; C2 = true;
end do end do
31
Aquí no se cumple la condición 4: es posible que C1 y C2
contengan el valor “false” en forma simultánea (por ejemplo,
C1 se puso en “false” y apareció una IRQ, pasando P2 a
ejecutarse con C2 también en “false”).
En tal caso los dos procesos entrarán en un lazo de bloqueo
indefinido: uno esperando por el otro, para su ingreso a su
respectiva SC.
Con C1 y C2 inicializados en “false” es imposible para P1 y P2
proseguir, quedan mutuamente trabados (interbloqueo).
32
Objetivo: evitar el bloqueo indefinido poniendo C1 y C2 en “true”
luego de chequear si son “false”.
Boolean C1 = C2 = true;{valor inicial de variables compartidas}
P1: P2:
C1 = false; C2 = false;
if not C2 then C1 = true; if not C1 then C2 = true;
else else
< SC1 > < SC2 >
C1 = true C2 = true;
end if end if
end do end do 33
Esta solución falla en la condición 3 y 4: si, p/ej. P2 siempre
chequea el indicador C1 justo después de que fue puesto en
“false” por P1 y, como resultado, pone a C2 en “true” antes
de que sea chequeado por P1; P1 siempre entrará en su SC,
mientras que se obliga a P2 a esperar (viola la condición 3).
El otro tipo de bloqueo se produce, por ejemplo, cuando P1 y P2
comienzan a ejecutar en forma simultánea y exactamente a
la misma velocidad. Esto puede motivar que estén
chequeando y modificando los indicadores indefinidamente
sin poder ingresar a sus respectivas SC[*].
[*] Este tipo de bloqueo indefinido tiene baja probabilidad de ocurrencia puesto
que, para que ocurra el bloqueo, ambos procesos deben mantener
exactamente la misma velocidad de procesamiento siempre. Si uno de
ellos ejecuta más rápido o más lento que el otro, el bloqueo mutuo se34
resuelve.
Fin de la clase
35
SOLUCIÓN POR HARDWARE
Existen diversas soluciones. Método más simple: exclusión mutua
deshabilitando las IRQ al procesador cuando un proceso se
encuentra en su SC. (usado por UNIX en 1eras. versiones).
El esquema es el siguiente: Pi:
deshabilitar IRQ´s
< SCi >
habilitar IRQ´s
Ventajas: simplicidad y posibilidad de resolución para todos los

procesos.
Desventajas: 1) no es aplicable en sistemas multiprocesador
(sería necesario inhabilitar las IRQ para todos los
procesadores lo que bajaría la eficiencia del procesamiento)
36
2) no es aplicable a SO´s de tiempo real.
SOLUCIÓN POR HARDWARE - función test&set
Otra solución es utilizar cierto tipo de instrucciones que poseen
algunos procesadores: permiten chequear y modificar el
contenido de una variable en forma indivisible o atómica.
(si una IRQ se presenta durante la ejecución de una
instrucción atómica, recién es atendida cuando finaliza el
procesamiento de dicha instrucción).
Un ejemplo de instrucción atómica es la función test&set:
function test&set (X: boolean); boolean;
begin
test&set = X;
X = false;
end 37
 test&set siempre devuelve el valor que poseía la variable X
cuando la invoca y establece el nuevo valor de X a “false”.
 tes&set es ejecutada atómicamente, como una unidad
ininterrumpible.
 Qué sucede con test&set cuando el sistema tiene más de un
procesador?
38
boolean X = true; {inicializa variable compartida}
P1:
do forever
while not test&set(X) do nop; {lazo de espera}
< SCi >
X = true;
end do
39
Ventajas:
Es aplicable a cualquier número de procesos tanto en sistemas
monoprocesador como en sistemas multiprocesador.
Es simple y, por lo tanto, muy fácil de verificar.
Puede ser utilizado para soportar múltiples secciones críticas.
Desventajas:
En su implementación, normalmente se emplean lazos de
espera donde la CPU utiliza ciclos sin ninguna computación útil
En ciertas circunstancias es posible que se provoque inanición
de procesos.
Es posible que aparezca bloqueo indefinido (“deadlock”),
dependiendo del tipo de planificador de CPU que utilice el SO.
40
Debido a las desventajas expuestas, las soluciones por
hardware no son generalmente empleadas en los SO
modernos.
41
Sistemas Distribuidos
 Un sistema distribuido está compuesto por varios
computadores interconectados por una red de comunicación.
 Cada computador tiene su propia memoria principal, la cual
no es compartida con ningún otro computador.
 Desde el punto de vista de un computador específico, el
resto de los computadores y sus correspondientes recursos
son remotos mientras que sus propios recursos son locales.
 La diferencia más notable entre los sistemas distribuidos y
los sistemas multiprograma o multiprocesador, es que en los
primeros no se comparte el mismo conjunto de recursos,
particularmente la memoria, entre los procesos intervinientes.
42
 Los sistemas componentes del sistema distribuido no
necesariamente deben ser iguales.
 Por el contrario, la aplicación práctica consiste en conectar
sistemas con diferentes configuraciones, diferentes SO´s, etc.
 La conexión es provista por un bus de alta velocidad o una red
de comunicación LAN, MAN o WAN.
Sistema B
Red de Comunicación
Sistema A
Sistema C Sistema D
43
Motivos de la importancia de los sistemas distribuidos:
 Compartimiento de Recursos.
Ejemplo: Un usuario de A puede usar una impresora
disponible en B, mientras un usuario de C puede utilizar un
disco de A.
 Mayor velocidad de procesamiento.
Si un proceso particular puede ser dividido en varios
procedimientos, éstos se pueden ejecutar concurrentemente
en varios sistemas (paralelismo físico). Además, si un
sistema se halla sobrecargado, algunos procesos podrían
migrarse a un sistema co menor carga.
44
 Confiabilidad (tolerancia a fallas).
Cuando un sistema deja de funcionar puede ser remplazado
por otro que está operativo
 Comunicación.
Consiste en establecer aplicaciones típicas de red
comunicadas entre los sistemas del SD, como la
transferencia de archivos, logeo remoto, correo electrónico,
etc. Ej: grupos de trabajo geográficamente separados pueden
desarrollar un mismo proyecto en forma cooperativa: transferir
archivos del proyecto, ingresar en los distintos sistemas para
correr programas, utilizar el correo electrónico para coordinar
tareas, etc.
45
Métodos de Sincronización basados en Mensajes
Primitivas “send” y “receive”
Son utilizadas para enviar y recibir datos de cualquier tipo entre
los procesos.
No existe una definición universal para send y receive. En forma
genérica, las sintaxis de estas primitivas podría ser:
• send (p,msg)
• receive (q,msg)
send: envía el mensaje msg (puede ser cualquier estructura de
datos) al proceso p.
receive: se usa para recibir un mensaje. q es el proceso que
espera el mensaje, mientras que msg es la estructura de
datos donde se depositará el mensaje.
46
Preguntas para entender la variedad de uso de las primitivas
send y receive:
1. Cuando un proceso envía un mensaje, ¿debe esperar hasta
que sea aceptado por el proceso receptor o puede continuar
procesando?
2. ¿Qué debería ocurrir cuando se invoca receive y no hay
mensaje para ser recibido?
3. El proceso que envía el mensaje ¿debe especificar el proceso
receptor, o el mensaje puede ser recibido por todos los
procesos?
4. El proceso receptor ¿tiene que especificar exactamente de qué
proceso está esperando un mensaje o puede aceptarlo de
cualquier proceso?
47
Las dos primeras preguntas tienen que ver con la comunicación,
mientras que las dos últimas están relacionadas con la
invocación de procesos.
La comunicación: puede ser sincrónica o asincrónica.
La invocación: puede ser implícita o explícita.
Respuestas a las preguntas formuladas.
Pregunta 1: Cuando un proceso envía un mensaje, ¿debe
esperar hasta que sea aceptado por el proceso receptor o
puede continuar procesando?
Existen dos posibles repuestas: si el proceso emisor se bloquea
hasta que el mensaje es aceptado, la primitiva send se
denomina sincrónica. Caso contrario se denomina
asincrónica.
48
Pregunta 2: ¿Qué debería ocurrir cuando se invoca receive y no
hay mensaje para ser recibido?
De igual forma que para 1, se puede tener una primitiva recieve:
- sincrónica o bloqueante: cuando se invoca receive y no hay un
mensaje, el proceso se bloquea esperando por él.
- asincrónica o no bloqueante: si no hay mensajes cuando la
primitiva es invocada, el proceso sigue procesando.
49
3. El proceso que envía el mensaje ¿debe especificar el
proceso receptor, o el mensaje puede ser recibido por todos
los procesos?
4. El proceso receptor ¿tiene que especificar exactamente de
qué proceso está esperando un mensaje o puede aceptarlo
de cualquier proceso?
Las preguntas 3 y 4 están orientadas a resolver el problema del
nombre de los procesos.
Resp. a 3: en el caso de send es muy común el envío del
mensaje a todos los procesos (broadcasting o nombramiento
implícito)
Resp. a 4: de igual forma, un proceso puede querer recibir
mensajes de cualquier proceso (primitiva receive con
nombramiento implícito).
Cuando el envío o recepción de mensaje es selectivo: primitivas
con nombramiento explícito. (Ver Tabla siguiente) 50
send Bloqueante No Bloqueante
Nombramiento Enviar el mensaje m al Enviar el mensaje m al
Explícito receptor r. Esperar hasta receptor r.
que m sea aceptado.
Nombramiento Enviar m a todos los Enviar m a todos los
Implícito procesos. Esperar hasta procesos.
que m sea aceptado.
recieve Bloqueante No Bloqueante

Nombramiento Esperar por mensaje del Si hay mensaje del
Explícito emisor s. emisor s, recibirlo; sino
continuar.
Nombramiento Esperar por mensaje de Si hay mensaje de

Implícito cualquier emisor. cualquier emisor,
recibirlo, sino continuar.
51
Formas de implementación de send y receive
1. Esquema más simple: Ambas operaciones son bloqueantes
(c/ nombto implícito o explícito). → Esquema de
comunicación sincrónico.
2. Una de las primitivas es no bloqueante, → la comunicación
es asincrónica.
La primitiva send bloqueante c/ nombto implícito es de poco
uso práctico debido a la complejidad de sincronizar el
proceso que emite el send con todos los posibles procesos
receptores. Así, Cuando se utiliza broadcasting se usa un
esquema de send no bloqueante.
3. Ambas versiones bloqueantes de receive: son útiles, en
particular, muchos problemas de sincronización no pueden
ser resueltos sin contar con la primitiva receive con nombto
implícito. 52
SINCRONIZACIÓN DE PROCESOS CON send y receive.
Resolución del problema de buffer limitado. (diap. Xx con un
proceso productor y uno consumidor, con buffer de tamaño 1).
Se utilizarán send y receive bloqueantes con nombto explícito.
Productor:
do forever
registro = producir registro();
send (consumidor, registro)
end do
Consumidor:
do forever
receive (productor, registro);
procesar registro;
53
end do
Limitación de la solución:
Usando sólo primitivas con nombramiento explícito, esta solución
no puede ser extendida al caso de un buffer de tamaño mayor
que 1.
Para llegar a una solución para el caso más general, deben
usarse primitivas con nombramiento implícito y explícito
(bloqueantes).
54
Comunicación a través de Buzones y Puertos
(“Mailboxes” y “Ports”)
En ausencia de primitivas receive c/ nombto implícito, un
proceso está limitado a recibir mensajes de una única fuente
en todo instante.
La idea básica es hacer que las colas que almacenan los
mensajes sean visibles a los procesos. Es decir, una primitiva
send no utiliza el nombre de un proceso como su destino;
sino que direcciona a una cola adónde el mensaje será
agregado.
De manera similar, la primitiva receive del proceso receptor
direcciona la cola desde la cual va aceptar los mensajes.
55
Buzón o Mailboox: cola direccionada por más de un proceso
transmisor. (Figura (a) sigte).
Es el método más general de comunicación ya que
cualquiera de los n transmisores puede emitir mensajes que
pueden ser recogidos por cualquiera de los m receptores.
Desafortunadamente, en los sistemas distribuidos la
implementación de operaciones receive puede ser bastante
costosa puesto que todas apuntan al mismo buzón.
Frecuentemente se implementa una versión limitada de un
mailboox, denominado puerto o “port”.
Puerto: todos los mensajes que provienen de diferentes procesos
son direccionados al mismo puerto, el que está asociado a
un único receptor. (Figura (b) sigte).
56
Comunicación a través de Buzón y Puerto
Procesos Procesos
Transmisores Receptores
S1 send receive R1
. .
. Buzón .
. receive .
send
Sn Rm
(a)
Procesos
Transmisores
S1 send
Proceso
Receptor
.
receive
. Puerto Q
.
send
Sn
57
(b)
Las Primitivas send y receive son una de las tantas primitivas
utilizadas en la sincronización de procesos que no utilizan
memoria compartida. La desventaja de estas primitivas es que
son de bajo nivel; esto significa que el programador se ve
forzado a intercalar en el medio de sus procedimientos de alto
nivel las primitivas send y receive.
Existen otras primitivas de alto nivel que son utilizadas para la
sincronización de procesos que no disponen de compartimiento
de variables.
Estas primitivas se basan en invocaciones a procedimientos
remotos llamadas comúnmente RPC (Remote Procedure Call)
58
Llamado a Procedimientos Remotos - RPC -
 Los RPC se utilizan para la sincronización de procesos en
sistemas distribuidos. (Es una variante de las primitivas de
pasaje de mensajes).
 Parte esencial de este esquema: permitir interactuar a los
programas en distintos computadores utilizando la misma
semántica usada para llamados a procedimientos locales; es
decir, como si los programas que interactúan estuvieran en la
misma máquina, con la salvedad de que no están.
 Los esquemas de sincronización basados en RPC son usados
en la mayoría de los SO´s (Ej: Windows NT, UNIX, entre otros).
59
Razones de la amplia aceptación de los RPC:
 La invocación de procedimientos es un mecanismo
ampliamente aceptado y utilizado desde hace décadas por los
programadores.
 El uso de RPC permite a las interfaces remotas ser
especificadas como un conjunto de operaciones con tipos de
datos perfectamente establecidos. De esta manera, la interfaz
puede ser claramente documentada.
 Al especificarse una interfaz bien definida y documentada, los
desarrolladores de software pueden escribir módulos clientes y
servidores que pueden moverse entre distintos computadores y
SO´s con mínimas modificaciones.
60
Visión de un RPC:
 Puede ser visto como una primitiva de alto nivel, si se lo
compara con las primitivas send() y receive() de pasaje de
mensajes.
 Desde el punto de vista del programador: tiene el mismo efecto
que una invocación a un procedimiento estándar local: se
transfiere el control a otro procedimiento, mientras se suspende
al programa que lo invoca.
 Una sentencia “return” ejecutada por el procedimiento
invocado, transfiere nuevamente el control al procedimiento
original, en dónde se continúa con la ejecución de la
instrucción que sigue luego del llamado al procedimiento
remoto.
61
Diferencia entre un procedimiento local y uno remoto:
Este último se ejecuta en un espacio de direcciones totalmente
separado y, por lo tanto, no se puede compartir ninguna
variable global.
Para el intercambio de información:
El programa que invoca al RPC debe pasar todos los valores al
procedimiento como parámetros de entrada.
De igual manera, los resultados son devueltos al proceso que
invoca el RPC como parámetros de salida.
62
Los RPC desde el punto de vista de la implementación:
Varían totalmente respecto de los procedimientos normales:
debido a que los procedimientos remotos ejecutarán en un
espacio de direcciones diferentes (posiblemente en otro
computador) no pueden ser parte del proceso que lo invoca.
Por lo tanto se debe crear un proceso separado para ejecutar
el RPC.
63
Fin Módulo 1
64

Clase 1 Java

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Clase 1 Java

Transféré par

Droits d'auteur :

Formats disponibles

Sistemas Operativos II

 Los SO´s modernos se diseñan a partir de los conceptos de

Productor Producir Buffer Consumir Consumidor

EJEMPLO DE PROCESOS COOPERATIVOS

Procesos Cooperación por Los resultados de un proceso pueden

Procesos Cooperación por Los resultados de un proceso pueden

Debe proveerse a los procesos

Debe proveerse a los procesos

Procesos Debe proveerse a los procesos

P1: P2: ... Pn:

Por ejemplo, supóngase que hay n aplicaciones (P1, P2, … Pn)

[*] Esto ocurre si estando P1 en su programa1, P2 ingresa a su

Ventajas: simplicidad y posibilidad de resolución para todos los

boolean X = true; {inicializa variable compartida}

recieve Bloqueante No Bloqueante

Nombramiento Esperar por mensaje de Si hay mensaje de

Vous aimerez peut-être aussi