Procesos en Un Sistema Operativo:transferencia de Mensajes

Descargar como pptx, pdf o txt
Descargar como pptx, pdf o txt
Está en la página 1de 20

TRANSFERENCIA DE MENSAJES:

*Utiliza dos llamadas al sistema en vez de comandos del lenguaje:


-send: Enva un mensaje a un destino especificado.
-receive: Recibe un mensaje de un origen especificado.
send(destino, &mensaje);
receive(origen, &mensaje);
Si no hay un mensaje disponible el receptor se bloquea hasta que llegue uno.

Aspectos de diseo para los sistemas con


pasaje de mensajes
Los sistemas con transferencia de mensajes pueden tener
grandes retos y aspecto de diseo.
Prdida de mensajes en la red.
Acuerdo entre emisor y receptor (mensaje de confirmacin).
Si el emisor no recibe una confirmacin reenva el mensaje.
El mensaje se recibe, pero la confirmacin se pierde: el emisor
retransmite el mensaje y el receptor lo tendr duplicado.
El receptor debe distinguir entre un mensaje nuevo y su
retransmisin.

Solucin:
Nmeros consecutivos en cada mensaje.
La autenticacin:
Es otro aspecto de los sistemas con mensaje, para esto,
es til el ciframiento de mensajes con una clave que slo
conozcan los usuarios autorizados.

El problema del productor y el


consumidor con transferencia de
mensajes
Mensajes del mismo tamao y los mensajes son enviados pero
no recibidos se almacenan en el buffer.
El consumidor enva N mensajes al productor. Cada vez que el
productor tiene un elemento para dar al consumidor, recibe un
mensaje vaco y enva uno lleno, el numero total de mensajes
permanece constante

Si el productor trabaja con mas rpidez que el consumidor, todos


los mensajes terminarn llenos esperando al consumidor, el
productor se bloquear esperando a que regrese un mensaje
vaco.
Si el consumidor trabaja con mas rapidez que el consumidor ,
todos los mensajes terminarn vacos esperando a que el
productor los llene.
Existen muchas variantes para la transferencia de mensajes, una
de ellas es le buzn. (Lugar para almacenar un nmero
determinado der mensajes, los cuales se especifican al crear el
buzn.)

Productor y consumidor:
Tanto el productor como el consumidor crearan
buzones con el tamao suficiente para N mensajes.
Productor enva mensajes con datos al buzn del
consumidor y el consumidor enva mensajes vacos al
buzn del productor.}
El buzn destino almacena los mensajes enviados al
proceso de destino pero tales que no hayan sido
recibidos todava.

Equivalencia de primitivas
Reed y Kanodia (1979) describieron otro mtodo de
comunicacin entre procesos llamado de
secuenciadores.
Campbell y Habberman(1974) analizaron el mtodo de
expresiones de trayectorias.
Atkinson y Hewitt(1979) introdujeron los
serializadores.
Todos los mtodos son en esencia equivalentes, se
puede utilizar cualquiera de ellos para construir los
dems.

Uso de semforos para la


implantacin de monitores y
mensajes

1) A cada proceso se le asocia un semforo con valor inicial 0, con el


cul se har un bloqueo cuando un send o receive deba esperar
para terminar.
2) Se utiliza un rea del almacn (buffer) para conservar los
buzones.
3) Las entradas de cada buzn se encadenan con una lista ligada,
para que los mensajes se entreguen en el orden que se reciben.
4) Por ltimo cada buzn contiene el inicio de dos colas:
Cola 1:Procesos que no se pueden enviar al buzn.
Cola 2:Procesos que no pueden recibir informacin del buzn.

Uso de monitores para implantar


semforos y mensajes
Se necesita un contador y una lista cargada para cada
uno de los semforos por implantar, adems de una
variable de condicin para cada proceso.
Down -> el proceso verifica si el contador se el
semforo es mayor que 0, si es as el contador se
decrementa y el proceso sale del monitor.
SI el contador es 0 , el proceso aade su propio
nmero de proceso y realiza un wait en su variable de
condicin.

Uso de mensajes para la


implantacin de semforos y
monitores
.

Problemas clsicos de la comunicacin entre


procesos
*El problema de la cena de los filsofos
En 1965 Dijkstra plante y resolvi un problema de sincronizacin .
Cinco filsofos se sientan a la mesa. Cada uno tiene un plato de espagueti. El espagueti es tan
escurridizo, que un filsofo necesita dos tenedores para comerlo. Entre cada dos platos hay
un tenedor.
Cuando un filsofo tiene hambre, intenta obtener un tenedor para su mano
izquierda y otro para su mano derecha, alzando uno a la vez y en cualquier orden.
SI logra obtener los dos tenedores , come un rato y despus deja los tenedores y
contina pensando.
*Se puede escribir un programa para cada filsofo que lleve a cabo lo que se
supone que debe hacer y nunca se detenga?

NO Solucin
#define N 5
void filosofo(int i)

/* nmero de filsofos */
/* i: nmero de filsofo, de 0 a 4 */

{
while(TRUE){
pensar();
tomar_tenedor(i);
tomar_tenedor((i+1) % N);
*/
comer();

/* el filsofo est pensando */


/* toma tenedor izquierdo */
/* toma tenedor derecho; % es el operador mdulo
/* come espagueti */

poner_tenedor(i);

/* pone tenedor izquierdo de vuelta en la mesa */

poner_tenedor((i+1) % N);

/* pone tenedor derecho de vuelta en la mesa */

En este procedimiento, tomar_tenedor espera hasta que el tenedor especificado est


disponible y lo toma.
*OCURRE UN BLOQUEO

Posible solucin

Problema

Se podra modificar el programa, de forma que despus


de tomar el tenedor izquierdo, el programa verificara si el
tenedor derecho est disponible. Si no, el filsofo deja el
izquierdo, espera cierto tiempo y vuelve a repetir el
proceso.

Todos los filsofos podran comenzar el algoritmo de manera


simultanea. (inanicin)

#define N 5
/* nmero de filsofos */
#define IZQUIERDO (i+N-1)%N
/* nmero del vecino izquierdo de i */
#define DERECHO (i+1)%N
/* nmero del vecino derecho de i */
#define PENSANDO
/* el filsofo est pensando */
#define HAMBRIENTO 1
/*el filsofo trata de obtener los tenedores */
#define COMIENDO 2
/* el filsofo est comiendo */
typedef int semaforo;
/* los semforos son un tipo especial de int */
int estado[N];
/* arreglo que lleva registro del estado de todos*/
semaforo mutex = 1;
/* exclusin mutua para las regiones crticas */
semaforo s[N];
/* un semforo por filsofo */
void filosofo(int i)
/* i: nmero de filsofo, de 0 a N1 */
{
while(TRUE){
/* se repite en forma indefinida */
pensar();
/* el filsofo est pensando */
tomar_tenedores(i);
/* adquiere dos tenedores o se bloquea */
comer();
/* come espagueti */
poner_tenedores(i);
/* pone de vuelta ambos tenedores en la mesa */
}
}
void tomar_tenedores(int i)
/* i: nmero de filsofo, de 0 a N1 */
{
down(&mutex);
/* entra a la regin crtica */
estado[i] = HAMBRIENTO
/* registra el hecho de que el filsofo i est hambriento */
probar(i);
/* trata de adquirir 2 tenedores */
up(&mutex);
/* sale de la regin crtica */
down(&s[i]);
/* se bloquea si no se adquirieron los tenedores */
}
void poner_tenedores(i)
/* i: nmero de filsofo, de 0 a N1 */
{
down(&mutex);
/* entra a la regin crtica */
estado[i] = PENSANDO;
/* el filsofo termin de comer */
probar(IZQUIERDO);
/* verifica si el vecino izquierdo puede comer ahora */
probar(DERECHO);
/* verifica si el vecino derecho puede comer ahora */
up(&mutex);
/* sale de la regin crtica */
}
void probar(i)
/* i: nmero de filsofo, de 0 a N1 */
{
if (estado[i] == HAMBRIENTO && estado[IZQUIERDO] != COMIENDO && estado[DERECHO] != COMIENDO) {
estado[i] = COMIENDO;
up(&s[i]);
}
}

SOLUCI
N

FINAL

Solucin final
Utiliza un arreglo estado para llevar un registro de la
actividad de un filsofo(pensando, comiendo o
hambriento).
Un filsofo puede comer slo si los vecinos no estn
comiendo.
Los vecinos del i-simo filsofo se definen en los macros
IZQUIERDO y DERECHO.
El programa utiliza un arreglo de semforos , uno por
cada filsofo, de manera que los filsofos hambrientos
pueden bloquearse si los tenedores necesarios estn
ocupados.

El problema de los lectores y


escritores.
Modela el acceso a la base de datos.
EL problema consiste en imaginar una gran base de
datos, por ejemplo un sistema de reservaciones en una
lnea area, con muchos procesos en competencia, que
intentan leer y escribir en ella.

Problema
Se puede aceptar que varios procesos
lean la base de datos al mismo
tiempo, pero si uno de los procesos
est escribiendo(modificando) la base
de datos, ninguno de los dems
procesos debera tener acceso a sta,
ni siquiera los lectores.

Solucin
El primer lector que obtiene el
acceso a la base de datos lleva
acabo un DOWN en el semforo
db. Los siguientes lectores
simplemente incrementan un
contador llamado cl.
A medida que los lectores van
saliendo, decrementan el
contador y el ltimo realiza una
operacin up en el semforo,
para permitir que un escritor
bloqueado (si lo hay) entre.

typedef int semaforo;


semaforo mutex=1;
semaforo bd=1;
int cl=0;
void lector(void)
{
while(TRUE){
down(&mutex);
cl = cl + 1;
if (cl == 1) down(&bd);
up(&mutex);
leer_base_de_datos();
down(&mutex);
cl = cl 1;
if (cl == 0) up(&bd);
up(&mutex);
usar_lectura_datos();
}
}
void escritor(void)
{
while(TRUE){
pensar_datos();
down(&bd);
escribir_base_de_datos();
up(&bd);
}
}

/* use su imaginacin */
/* controla el acceso a cl */
/* controla el acceso a la base de datos */
/* # de procesos que leen o desean hacerlo */
/* se repite de manera indefinida */
/* obtiene acceso exclusivo a cl */
/* ahora hay un lector ms */
/* si este es el primer lector ... */
/* libera el acceso exclusivo a cl */
/* accede a los datos */
/* obtiene acceso exclusivo a cl */
/* ahora hay un lector menos */
/* si este es el ltimo lector ... */
/* libera el acceso exclusivo a cl */
/* regin no crtica */

/* se repite de manera indefinida */


/* regin no crtica */
/* obtiene acceso exclusivo */
/* actualiza los datos */
/* libera el acceso exclusivo */

Problema
Suponga que mientras un lector utiliza la
base de datos, llega otro lector. Como no
es un problema tener dos lectores al
mismo tiempo, el segundo lector es
admitido. Tambin se pueden
admitir ms lectores, si es que llegan.
Ahora suponga que aparece un escritor. Tal
vez ste no sea admitido a la base de
datos, ya que
los escritores deben tener acceso
exclusivo y por ende, el escritor se
suspende. Ms adelante aparecen
lectores adicionales. Mientras que haya un
lector activo, se admitirn los siguientes
lectores.
El escritor estar suspendido hasta que no
haya un lector presente.

Solucin
Para evitar esta situacin, el programa
se podra escribir de una manera
ligeramente distinta:
Cuando llega un lector y hay un
escritor en espera, el lector se
suspende detrs del escritor, en vez
de ser admitido de inmediato.
De esta forma, un escritor tiene que
esperar a que terminen los lectores
que estaban activos cuando lleg,
pero no tiene que esperar a los
lectores que llegaron despus de l.

También podría gustarte