METODOS INDIRECTOS

Grupo Digitalización. Integrantes: Acosta, Artesi, Fassari, Flook
FIN DE SINCRONIZACIÓN Y COMUNICACIÓN ENTRE PROCESOS CONCURRENTES
Sincronización entre procesos (CONCURRENTES): ordenamiento en el tiempo de las
operaciones, debido a condiciones de carrera (RACE CONDITIONS). A simultaneidad de pedidos
de un recurso único, secuenciamiento de su uso. Solución para la race condition: colocar una
valla con cerrojo (LOCKEO) para cada recurso crítico.
La sincronización permite que un proceso continué su ejecución luego de ocurrido un evento
(por el que estaba esperando su ocurrencia) la sincronizaron se necesita para FORZAR la
EXCLUSION MUTUA entre proceso.
Comunicación (entre procesos): es un intercambio de datos que permite que los procesos
intervinientes (en dicho intercambio) cooperen entre si a efectos de de llevar a cabo un
objetivo global.
LA COOPERACION ENTRE PROCESOS SE PUEDE LLEVAR A CABO DE DOS MANERAS DIFERENTES
1. A trabes de un área común de memoria (cooperation by sharing)
2. Mediante el intercambio de mensajes (cooperation by comunication).
Caso 1: (área común de memoria): se necesitan una serie de mecanismos de sincronización
(semáforos, monitores, etc.) para garantizar la consistencia de los datos allí almacenados. Ej.:
productor – consumidor.
Caso 2: (intercambio de mensajes): en este caso las variables son locales. PROPOSITO: permitir
que dos procesos se sincronicen o se envíen datos mediante un mecanismo EXPLICITO.
Mensaje: porción discreta de datos (generalmente un conjunto de bits) consistente en
HEADER CUERPO
Cuando los procesos interactúan entre si se deben satisfacer dos requisitos fundamentales:
sincronización y comunicación. Los procesos necesitan SINCRONIZARSE para forzar la EM, y
necesitan del INTERCAMBIO DE INFORMACIÓN para llevar adelante la cooperación entre ellos.
Una aproximación (o intento) para proveer a los procesos de ambas funciones es el PASO DE
MENSAJES. La ventaja del Paso de Mensajes es que conlleva LA IMPLEMENTACIÓN DE estas
funciones tanto en sistemas distribuidos como en sistemas monoprocesadores y en sistemas
con múltiples procesadores compartiendo memoria.
Los sistemas de paso de mensajes vienen en varios “sabores” (modalidades de intercambio de
información). La función de paso de mensajes viene implementada a trabes de un par de
primitivas

SEND: (destino, número de mensaje, mensaje)

RECEIVE: (origen, numero de mensaje, &mensaje)
-1-
Grupo Digitalización. Integrantes: Acosta, Artesi, Fassari, Flook
Este es el mínimo conjunto, de operaciones necesarias para que los procesos lleven a cabo la
función de paso de mensajes.
Su proceso (transmisor) envía información en forma de mensaje a otro proceso (Receptor)
indicado en el destino del mensaje a trabes de SEND. A su vez un proceso recive información
ejecutando la primitiva RECEIVE e indicando en ella el origen del proceso que envía el mensaje
y el mensaje. Hay una serie de cuestiones relacionadas con el DISEÑO DE LOS SISTEMAS de
paso de mensajes.
1. Sincronización entre los procesos que emiten las dos primitivas (SEND y RECEIVE).
2. Direccionamiento de cada mensaje (identificación de los procesos intervinientes en el
paso de mensajes)
3.
Formato de los mensajes.
4. disciplina de encolado de los mensajes recibidos.
Estas cuatro cuestiones determinan los distintos sistemas de mensajes existentes en el
mercado (o sistemas de comunicaciones).
Transmisor
Receptor
mensaje
reconocimiento
Por diferencia de velocidad de los procesos TRANSMISOR y RECEPTOR (T>R) el sistema de
PASO de MENSAJES va a requerir del uso de un buffer para amortiguar las fluctuaciones de
velocidad relativa de los procesos TRANSMISOR y RECEPTOR.
Para T y R se comuniquen se necesita un vínculo de comunicación (comunicación LINK) con las
siguientes características:
1. nombre de los procesos asociados (origen T, destino R)
2. capacidad de vinculo (buffer space y transmisión space)
3. tamaño de cada mensaje
4. dirección del vinculo (unidireccional o bidireccional), half/ full duplex
TIPOS DE COMUNICACIÓN ENTRE PROCESOS
DIRECTA: los procesos envían y reciben los mensajes entre si. Dependen de las velocidades
relativas entre ellos (si las velocidades son distintas sincronizan vía un buffer de MENSAJES)
TX
RX
-2-
Grupo Digitalización. Integrantes: Acosta, Artesi, Fassari, Flook
INDIRECTA: los mensajes son enviados a un buzón (Mail Box) por el TRANSMISOR; y el
RECEPTOR retira del buzón.
MAILBOX
RX
TX
LOS MENSAJES VAN Y VIENEN A
BUZONES
Propiedades de las comunicaciones:
DIRECTA
1. AUTOMATICAMENTE se establece un vínculo (de comunicaciones) entre ambos
procesos TRANSMISON y RECEPCION. Solo deben conocerse mutuamente (el PID del
otro proceso).
2. el vínculo de comunicaciones se establece con exactamente dos procesos.
3. El vinculo es bidireccional full duplex
INDIRECTA
1. el vínculo se establece solamente si ambos procesos comparten un buzón.
2. el vinculo (LINK) puede ser asociado con mas de dos procesos. Ej.: broadcast
3. un link puede ser UNI o BI direccional.
4. entre cada par de procesos puede haber varios links distintos, cada link
correspondiente a un buzón. Ej.:
TX
MAILBOX
RX
RX
TX
RX
COMUNICACIÓN ENTRE PROCESOS

Mensajes

Inter Process Communications

Sincronización mediante mensajes

Modelo Productor – Consumidor
-3-
Grupo Digitalización. Integrantes: Acosta, Artesi, Fassari, Flook
RPC (remote procedure call) es una variante del modelo de paso de mensajes (message
passing). Es un método para encapsular comunicaciones en un sistema distribuido.
La esencia de esta técnica (RPC) es permitir que programas residentes en distintas maquinas
interactúen entre ellos usando una semántica de call/return entre procesos; tal COMO SI LOS
DOS PROGRAMAS estuvieran en la MISMA maquina. El RPC se usa para acceder a servicios
remotos.
Al mecanismo de los RPC se lo ve como un refinamiento de paso de mensajes SEGURO y
BLOQUEANTE.
CARACTERISTICAS DE DISEÑO DE SISTEMAS de PASO de MENSAJES para IPC y sincronización
1. SINCRONIZACION
2. DIRECCIONAMIENTO
3. FORMATO
4. DISCIPLINA DE ENCOLADO
1) SINCRONIZACION: la comunicación de mensajes entre dos procesos IMPLICA algún nivel
de sincronización entre ambos procesos: el receptor no puede recibir un mensaje hasta que
otro proceso lo haya enviado. Además se debe especificar que sucede con un proceso luego de
haber emitido una primitiva SEND o RECEIVE.
Analicemos primero el SEND: cuando un proceso emite un SEND pueden ocurrir dos cosas:
BLOQUEANTE: el proceso que emite el SEND se bloquea hasta que se reciba el
mensaje enviado
SEND
NO BLOQUEANTE: el proceso continúa trabajando luego del SEND
Si un proceso emite un RECEIVE pueden ocurrir dos cosas:
a) si previamente al receive algún proceso envió un mensaje entonces se recibe
el mensaje y el proceso continua.
b) Si no hay un mensaje en espera, hay dos posibilidades:
b)1) El proceso se bloquea hasta que llegue un mensaje (RECEIVE
BLOQUEANTE).
b)2) El proceso continua su ejecución, abandonando el intento de recibir el
mensaje. Recepción NO BLOQUEANTE.
Hay tres combinaciones que son las más comunes, aunque en general cualquier sistema de
comunicaciones solo soporta una de ellas (a lo sumo dos, no las tres).
-4-
Grupo Digitalización. Integrantes: Acosta, Artesi, Fassari, Flook
a) SEND BLOQUEANTE, RECEIVE BLOQUEANTE: ambos procesos (TRANSMISION y
RECEPCION) se bloquean hasta que el mensaje es entregado (a este tipo de
comunicación se lo llama RENDEZ VOUS). Esta combinación permite una sincronización
muy ajustada (estricta) entre los dos procesos intervinientes. Se usa en
comunicaciones directas.
b) SEND NO BLOQUEANTE, RECEIVE BLOQUEANTE: es quizás la combinación más útil.
Permite que un proceso envié uno o mas mensajes a un conjunto de destinos en la
forma mas rápida posible. El proceso que deba recibir un mensaje antes de continuar
con su trabajo útil, deberá bloquearse hasta que el mensaje llegue. Ej.: procesos
servidores de servicios (o de recursos) a otro procesos.
c) SEND NO BLOQUEANTE, RECEIVE NO BLOQUEANTE: a ningún participante (en la
comunicación) se le solicita esperar.
El send No Bloqueante es el mas natural en programación de tareas concurrentes.
POTENCIAL PROBLEMA: un error puede hacer que se generen muchos mensajes (no hay
una forma de disciplinar a este proceso para que se interrumpa) consumiendo recursos del
sistema: tiempo de procesador y áreas de buffer, en detrimento de otros procesos e
incluso del mismo SO. El send No Bloqueante exige que sea el programador el encargado
de determinar que cada mensaje se haya recibido correctamente. Los procesos deberán
generar mensajes para dar a conocer la ORRECTA recepción de cada mensaje. El receive
bloqueante es lo usual para programar tareas concurrentes. Esto en un sistema distribuido
puede generar DEAD LOCK si un mensaje se pierde en la red o si el proceso que debía
enviar el mensaje se bloquea antes del envió. Este problema se PUEDE RESOLVER con un
receive no bloqueante. Pero surge otro problema: si un mensaje se envía luego de su
correspondiente receive, el mensaje se pierde. Intentando resolver todas estas cuestiones
surge el método TEST FOR ARRIVAL (Prueba de Recepción): otra alternativa consiste en
permitir que un proceso averigüe si hay algún mensaje para el en espera, en cuyo caso si
emite el receive correspondiente. Y permite que un proceso especifique más de un origen
en la primitiva RECEIVE. Este esquema es útil para un proceso que ESTA ESPERANDO POR
mensajes provenientes de múltiples orígenes. Permite que este proceso continué si
cualquiera de esos mensajes es recepcionado.
2. DIRECCIONAMIENTO: como ya se vio la primitiva SEND debe especificar que proceso
debe recibir cada mensaje. Análogamente la mayoría de las implementaciones (de un
sistema de comunicaciones) permite que el proceso receptor especifique el origen del
mensaje que quiere recibir. Los variados esquemas para especificar procesos en las
primitivas SEND y RECEIVE caen en dos categorías: direccionamiento
DIRECTO
INDIRECTO
2)a) Direccionamiento DIRECTO: la primitiva SEND incluye el PID del proceso destino. La
primitiva RECEIVE se puede manejar de dos formas:
-5-
Grupo Digitalización. Integrantes: Acosta, Artesi, Fassari, Flook
2)a)i) El proceso explícitamente designa al proceso emisor, con lo cual el proceso debe
conocer en forma anticipada de que proceso espera un mensaje, esto es EFECTIVO cuando
es usado en procesos cooperantes concurrentes (cooperating concurrent processes).
2)a) ii) EN OTRO CASOS, cuando es imposible especificar en forma anticipada al proceso
emisor del mensaje a leer, se usa el direccionamiento directo implícito: en este caso el
parámetro ORIGEN de la primitiva receive posee un valor que se retorna luego de
ejecutada la operación de recepción.
2)b) Direccionamiento INDIRECTO: en este caso los mensajes no se envían directamente
del proceso transmisor al proceso receptor, sino que se envían a una estructura de datos
(compartida por ambos procesos) consistente en colas que pueden retener los mensajes
temporariamente. A estas colas se las llama BUZONES (mailboxes). Aquí para que dos
procesos se intercomuniquen es necesario que un proceso envié un mensaje al buzón
apropiado, y que el otro proceso retire el mensaje del buzón en cuestión.
La relación entre transmisores y receptores puede ser:
a) uno a uno
b) Varios a uno
c) Uno a varios
d) Varios a varios
La relación uno a uno permite establecer un vinculo privado entre ambos procesos, libre de la
interferencia errónea por parte de otros procesos. En la relación varios a uno al buzón se lo
denomina PROT. Es útil en una interacción CLIENTS – SERVER donde un proceso provee de
servicio a varios procesos, el servidor va a tener un port de entrada. La relación uno a varios
permite un transmisor y muchos receptores, es útil para aplicaciones donde un proceso envía
mensajes o información a un conjunto de procesos en forma simultanea (broadcast a un
conjunto de procesos).
A su vez la asociación procesos buzones puede ser
ESTATICA
DINAMICA
Generalmente los ports se asignan a un proceso en forma estática, esto es: un port se crea y se
asigna a un proceso PERMANENTEMENTE. De la misma forma una relación uno a uno se define
estática y permanentemente.
Cuando hay muchos transmisores (senders) la asociación de un origen con un buzón se puede
efectuar dinámicamente, para ello se usan las primitivas connect y disconnect.
Otro asunto a analizar es la propiedad del buzón (O sea, que proceso es su dueño). En el caso
de un PORT, típicamente es el dueño quien lo posee y lo crea: El proceso receptor (O sea, el
proceso servidor). Aquí cuando el proceso se destruye, el Port también se destruye.
-6-
Grupo Digitalización. Integrantes: Acosta, Artesi, Fassari, Flook
En el caso de los Buzones (Mail Boxes) generales, el S.O. es quien ofrece el servicio de creación
de buzones. En estos, si el S.O. le asigna la propiedad del buzón al proceso que pide su
creación, esos buzones desaparecen al desaparecer el proceso “Dueño” del buzón. Si en
cambio el S.O. retiene la propiedad del buzón creado (A través de uno de sus servicios) en este
caso se necesita de un comando explicito para que se produzca su destrucción.
3) FORMATO DE LOS MENSAJES: Depende de los objetivos del dispositivo de mensajería
(Messaging Facility). Además el formato de los mensajes depende de que el dispositivo de
mensajera corra en un solo computador, o en un sistema distribuido (Red mediante). Para
algunos S.O. los diseñadores prefieren mensajes cortos y de longitud fija con el objeto de
minimizar Overhead de procesamiento y de almacenamiento. En estos casos si deseo pasar
una gran cantidad de datos, los datos se colocan en un archivo, y el mensaje simplemente hace
referencia a ese archivo donde almacena los datos. Una aproximación más flexible es permitir
la transmisión de mensajes de longitud variable.
Veamos ahora un formato de mensajes típico para S.O. que soportan mensajes de longitud
variable: El mensaje se divide en dos partes:
-
Un encabezamiento: Conteniendo información acerca del mensaje.
-
Un cuerpo: Que contiene al mensaje en si.
Tipo de Mensaje
Encabezamiento
Formato general de
(Header)
Destino (ID)
Origen (Id)
un mensaje de
Longitud del Mensaje
longitud variable
Información de control
Numero de Secuencia
Prioridad
Cuerpo
(Body)
Pointer
Contenido del mensaje
El campo Tipo permite discriminar entre varios tipos de mensajes. El campo puntero permite
crear una lista de mensajes encadenada. El numero de secuencia para controlar la cantidad y
el orden de los mensajes intercambiados entre fuentes (Orígenes) y destinos.
4) DISCIPLINA DE ENCOLADO (QUENING DISCIPLINE): Lo común es efectuar en
tratamiento FIFO, pero esto no es suficiente si algunos mensajes son más urgentes que otros.
Para esto tengo tres alternativas:
a) Se usa un campo PRIORIDAD dentro del header.
b) Se usa el tipo de cada mensaje.
-7-
Grupo Digitalización. Integrantes: Acosta, Artesi, Fassari, Flook
c) Se permite que el receptor inspeccione la cola de mensajes y seleccione que mensaje
se reciba próximamente.
Veamos como se usa el paso de mensajes para forzar la exclusión mutua. Se usa un RECIVE
Bloqueante y un SEND No Bloqueante. Un conjunto de procesos P1, …, Pn comparten un buzón
llamado MUTEX, inicialado para contener un solo mensaje con contenido nulo. El proceso que
desea ejecutar la R.C. primero intenta recibir este mensaje de contenido nulo. Si el buzón esta
vacío el proceso se bloquea. Una vez adquirido este mensaje, el proceso ejecuta la R.C.
controlada por este buzón. Al finalizar la R.C. el proceso vuelve a colocar este mensaje nulo en
el buzón donde lo saco. De esta forma este mensaje funciona como TOKENS (En una red Token
Ring). Esta solución asume que si más de un proceso efectúa una operación RECIVE en forma
concurrente, entonces:
-
Si hay un mensaje (En el buzón) se le entrega a un solo proceso y los otros se
bloquean, ó
-
Si el buzón esta vacío, todos los procesos se bloquean. Cuando haya un mensaje
disponible, solo un proceso bloqueado se va a activar (Al cual se le entregará este
mensaje).
Estas presunciones son ciertas en casi todos los sistemas de paso de mensajes.
Hay un ejemplo (Pág. 247) de Productor-Consumidor con Buffer acotado.
Previo a tratamientos de D.L. dar ejemplo de transacciones (Ej.: Noviazgo con y sin embarazo)
y de Roll Back de recursos (0 Km. de la novia si no se concreta la transacción, Casamiento).
Conceptos:
-
Commit: Compromiso, llevar adelante la transacción.
-
Roll Back: Volver atrás la transacción.
ABRAZO MORTAL:
Los
recursos
se
dividen
en 2
tipos:
Reusables: Recurso que puede ser usado con seguridad por un solo proceso por
vez y no se destruye con ese tipo de uso. Ej.: Procesadores, canales de E/S,
memoria primaria y secundaria, dispositivos y estructuras de datos: Semáforos,
archivos y bases de datos.
Consumibles: Recurso que se crea (Se produce) y se destruye al ser usado
(Consume). No hay límite en cuanto a la cantidad de recursos consumibles de
cualquier tipo. Un proceso no bloqueado puede producir cualquier cantidad de
tales recursos. Cuando uno de estos recursos es tomado por un proceso, el
recurso deja de existir. EJ.: Interrupciones, señales, mensajes e información en
buffers de E/S. Receives bloqueantes puede generar Dead Lock (Pág. 271).
-8-
Grupo Digitalización. Integrantes: Acosta, Artesi, Fassari, Flook
No existe una estrategia única para el tratamiento de Dead Lock.
Ignorarlo.
Posibles
estrategias en
el tratamiento
de Dead Lock:
Prevenirlo.
Evitarlo.
Detectarlo (Y corregirlo).
Exclusión Mutua: Un recurso solo puede ser usado por un solo proceso a la vez.
Condiciones
para que se
produzca el
Dead Lock:
Espera con retención (Hold & Wait): Un proceso retiene todos los recursos mientras espera que
se le asignen otros recursos que ha solicitado.
Apropiatividad (No Preemption): No se puede forzar la devolución de un recurso que es retenido
por un proceso. La asignación del recurso es retentiva.
Espera circular: Existe una cadena cerrada de procesos que retienen al menos un recurso
necesario (Y por el cual expresa) el siguiente proceso de la cadena.
Las tres primeras son condiciones necesarias (Puede no existir Dead Lock aunque las tres
primeras condiciones estén presentes) y son las que a la larga conducen a la aparición de la
cuarta condición (Espera circular). Las cuatro condiciones ya…..
No se lee en la fotocopia este renglón.
En muchos casos la pertenencia de las 3 primeras condiciones son deseables (Para llevar
adelante la multiprogramación y el multiproceso, “Anche” el procesamiento distribuido).
Por ejemplo, la exclusión mutua se necesita tanto para asegurar la consistencia de resultados y
la integridad de una base de datos. En forma análoga, la No Apropiatividad (Preemption) no se
puede llevar a cabo arbitrariamente (Especialmente cuando hay involucrados recursos “Dato”).
La no apropiatividad debe ser soportada por un mecanismo de recuperación denominado
ROLL BACK (Que relanza un proceso y sus recursos en base a un estado previo a su
interrupción (Cese del uso del/os recurso/s). En ese caso previo a la interrupción debo dejar el
estado de todos los recursos en el mismo estado en el que se encontraban previo al
lanzamiento interrumpido, a fin de que el proceso pueda (Al reanudar su actividad) repetir sus
acciones interrumpidas.
PREVENCION DEL DEAD LOCK:
Para llevara adelante esta estrategia se debe diseñar un sistema en el cual se Excluya la
posibilidad de un Dead Lock. Se (Restringen/Condicionan) los pedidos de recursos para
prevenir la ocurrencia de al menos una de las condiciones necesarias y suficientes del Dead
Lock.
-9-
Grupo Digitalización. Integrantes: Acosta, Artesi, Fassari, Flook
Clases de
metodos para
prevenir el
Dead Lock:
1) Metodos indirectos: Consiste en prevenir la ocurrencia de al
menos una de las tres condiciones necesarias para la
ocurrencia de Dead Lock.
2) Metodos directos: Consisten en prevenir la ocurrencia de la cuarta
condicion (Espera circular).
METODOS INDIRECTOS
1. Evitar la exclusión mutua: si el acceso a un recurso requiere de EM, esta condición no
se puede evitar. Pero DEBE ser soportada por el SO. Algunos recursos (ej.: archivos)
permiten múltiples accesos por parte de procesos escritores. En este caso se da la
posibilidad del DL cuando mas de un proceso requiere FALTA TEXTO
2. Evitar la espera con retención: esto requiere que un proceso solicite todos sus recursos
al mismo tiempo (digamos antes de pasar de NEW a READY) y que quede bloqueado
hasta tanto se le pueda asignar todo lo solicitado. Este esquema es INEFICIENTE desde
varios aspectos:
2)a) Un proceso queda bloqueado hasta que todo lo que pida esta disponible, aun
cuando con solo algunos recursos podría haber terminado. Incluso espero por recursos
que quizá en esta corrida no uso en absoluto.
2)b) Los recursos así asignados (todos de una vez) permanecen denegados a otros
procesos aun cuando el proceso que los tiene asignados los use muy de vez en cuando
o no los use en absoluto (en esta corrida). Mal aprovechamiento de los recursos.
2)c) El proceso debe conocer por adelantado todos los recursos que va a necesitar. Un
gran problema en aplicaciones modularmente programadas con procesos
concurrentes o estructurados como multihilos, la aplicación debería conocer para esa
corrida que recursos va a necesitar cada uno de sus hilos en el momento de solicitar su
ejecución, para efectuar el pedido simultáneo de todos los recursos necesarios para
esa corrida.
3. Evitar la apropiatividad. Esto se puede lograr de dos maneras
3)a) Si a un proceso que tiene retenido un conjunto de recursos se le niega una
asignación posterior entonces a ese proceso se le liberan todos los recursos ya
asignados. Y si es necesario antes de reiniciarlo se le asignan todos los recursos
desasignados más los que acababa de pedir en el momento de ser interrumpido en su
ejecución.
- 10 -
Grupo Digitalización. Integrantes: Acosta, Artesi, Fassari, Flook
3)b) Si un proceso P1 requiere un recurso que en estos momentos esta siendo retenido
por un proceso P2 entonces el SO puede desapropiar (preempt) al proceso P2,
obligándolo a liberar sus recursos. Esto solo tiene sentido si ambos procesos tienen la
MISMA PRIORIDAD de ejecución.
Cuando el estado de los recursos involucrados se pueden salvar con facilidad a fin de
ser reestablecidos (restored) cuando se reasignan con posterioridad.
Ejemplo: el procesador- la memoria principal (roll in – roll out)
METODO DIRECTO
4. Evitar la espera circular: se logra estableciendo un ordenamiento lineal de los tipos de
recursos permitiendo la asignación de los mismos de un orden estrictamente mayor al de
mayor orden actualmente asignado. Ej.: si actualmente un proceso P1 tiene asignados
recursos tipo R1, R2,…,Ri y solicita un recurso Rk solo se lo asigno si k>i.
Desventajas:
a) establecer el ordenamiento de recursos de recursos (dos instalaciones con igual
equipamiento usan de la misma forma cada uno de los componentes).
b) Análogamente al caso de evitar las dos condiciones (retener y esperar) este método
del ordenamiento lineal conlleva ineficiencia en el uso de los recursos en forma
innecesaria [el recurso Rk quizás solo es solicitado por P1 en el ejemplo])La prevención de DL (restringir o condicionar el pedido de recursos para prevenir la ocurrencia
de al menos una de las 4 condiciones necesarias y suficientes para la existencia del mismo).
Conlleva tanto a un uso ineficiente de los recursos como una ejecución indeficiente de los
procesos.
EVITAR EL DL (Avoidance)
Por el contrario, el evitar permite la ocurrencia de las tres primeras condiciones [EM, Hola and
Wait, Apropiatividad (Non Preemption)] pero hace elecciones juiciosas al asignar cada nuevo
recurso solicitado para asegurarse que el punto de DL no se alcanzara jamás.
Actual pudiera llevar (si se efectúa la asignación) potencialmente a un DL. Veremos dos
implementaciones posibles:
1. Negación de la iniciación del proceso
2. Negación de la asignación del recurso
Caso 1: no lanzar (start) un proceso si sus requerimientos pudieran ocasionar un DL.
Caso 2: no permitirle a un proceso efectuar un pedido de recurso si su asignación pudiera
conducir a un DL.
- 11 -
Grupo Digitalización. Integrantes: Acosta, Artesi, Fassari, Flook
Método 1: (Process Initiation Denial)
Consideremos un sistema con m distintos tipos de recursos y con n procesos corriendo
simultáneamente. Definamos los siguientes vectores y matrices.
Vector de recursos totales del sistema (cantidad total de cada recurso en el sistema)
R= (R1, R2,…,Rm)
VR: resource (recurso)
Vector de recursos disponibles (en estos momentos) en el sistema (cantidad total de cada
recurso no asignado a ningún proceso).
VV: available (disponible)
V= (V1,V2,…,Vn)
Matriz de pedidos o solicitudes (c: clain) donde cij es la cantidad total de recurso j solicitada
por el proceso i.
Matriz de asignación (A: allocation) donde aij es la cantidad actual del recurso j asignado al
proceso i.
C=
A=
R1
R2
RM
P1
C11
C12
C1M
P2
C21
C22
C2M
PN
CN1
CN2
CNM
R1
R2
RM
P1
A11
A12
A1M
P2
A21
A22
A2M
PN
AN1
AN2
ANM
Cada fila de la matriz C esta dedicada a un proceso y representa los requerimientos máximos
de cada recurso que efectúa dicho proceso.
- 12 -
Grupo Digitalización. Integrantes: Acosta, Artesi, Fassari, Flook
Esta información debe ser declarada con anticipación por parte del proceso para que todos los
algoritmos funcionen. FALTA TEXTO
1. Todos los recursos están asignados o disponibles
2. Ningún proceso puede solicitar mayor cantidad de un determinado recurso a la
existente en el sistema
3. A ningún proceso se le deben asignar (por cada tipo de recurso) una cantidad mayor a
la originalmente solicitada al sistema.
Caso 1:
Para evitar DL: lanzar (start) un proceso nuevo Pn+1 solo si
Un nuevo proceso solo se lanza si el máximo de requerimientos de todos los procesos actuales
más los requerimientos del nuevo proceso se pueden satisfacer. Esta estrategia dista de ser
óptima pues supone lo peor: que todos los procesos van a efectuar el máximo de sus
solicitudes en forma conjunta (o concurrente).
Caso 2:
Negación de la asignación de recurso (también conocida como algoritmo del banquero). Para
ello es necesario introducir los conceptos de estado y estado seguro. Consideremos un sistema
con un numero fijo de procesos Pi y un numero fijo de recursos Rj. En cualquier instante un
proceso puede tener asignados cero o mas recursos. El estado del sistema es simplemente la
asignación actual de recursos a los procesos. Entonces el estado consiste de los dos vectores
ya vistos [R: resource (recurso) y V: available (disponible)] y las dos matrices ya definidas (C:
solicitudes, A: asignaciones).
Un estado seguro es aquel en el cual existe al menos una secuencia (de asignaciones) que no
genera DL; o sea FALTA TEXTO
Un estado es inseguro cuando no es seguro (o sea que no se puede encontrar una secuencia
de asignaciones que permita la finalización de todos los procesos).
El algoritmo del banquero establece: (asegurando que el sistema siempre va a estar en estado
seguro) cuando un proceso efectué el pedido de un conjunto de recursos, suponga que la
solicitud se satisface, actualice el estado del sistema de acuerdo a estas asignaciones, y
determine si el resultado es un estado seguro. Si es seguro satisfaga el pedido. Si es inseguro
entonces bloquee el proceso hasta tanto sea seguro el satisfacer dicho pedido.
El estado inseguro es condición necesaria para un DL, no condición suficiente (un estado
inseguro puede no ocasionar DL). Es estado inseguro no es estado DL.
La estrategia de evitar no predice un DL, solamente se anticipa a la posibilidad de DL. Y
asegura que dicha posibilidad no va a ocurrir jamás.
- 13 -
Grupo Digitalización. Integrantes: Acosta, Artesi, Fassari, Flook
Ventajas del método de evitar el DL:
1) no es necesario desapropiar (preempt) y roll bachear procesos
2) es menos restrictiva que la prevención
Restricciones de uso
1) cada proceso debe conocer por anticipado la cantidad máxima de requerimientos de
cada recurso
2) los procesos analizados deben ser independientes (no debe haber ningún tipo de
cooperación entre ellos, que exija sincronización). Son todos procesos no
sincronización
3) debe existir un numero fijo de recursos a asignar
4) ningún proceso puede efectuar una salida exit reteniendo recursos.
- 14 -