Anexo Tema 1.

sistemas operativos:
Gestion de procesos
INDICE:
1.-CONCEPTO DE PROCESO.
2.-TIPOS DE PROCESO.
2.1. CARACTERISTICAS
3.-COMUNICACIN ENTRE PROCESOS
3.1.CONDICIONES DE CARRERA.
3.2. SECCIONES CRITICAS.
3.3. EXCLUSIN MUTUA
3.3.1. EXCLUSION CON ESPERA ACTIVA.
3.3.2. PROHIBICIN DE LAS INTERRUPCIONES.
3.3.3. VARIABLES CERROJO.
3.3.4. ALTERNANCIA ESTRICTA.
3.3.5. LA SOLUCIN DE PETERSON.
3.3.6. ALGORITMO DE DEKKER.
3.3.7. DORMIR Y DESPERTAR.
3.3.8. SEMAFOROS.
3.3.9. MONITORES.
3.3.10. MENSAJES
4.-GESTIN DE PROCESOS.
5.-ESTADOS DE UN PROCESO.
6.-PLANIFICACIN DE PROCESOS.
6.1.PLANIFICACIN POR TURNO ROTATORIO
6.2.PLANIFICACIN POR PRIORIDADES
6.3.LISTAS DE ESPERA MLTIPLES.
6.4.PRIORIDAD AL MS CORTO.
7.- INTERBLOQUEOS
7.1. CARACTERIZACIN DEL INTERBLOQUEO
7.2. PREVENCIN Y EVITACIN DE INTERBLOQUEO
7.3. DETECCIN DE LOS INTERBLOQUEOS
7.4. RECUPERACIN DE INTERBLOQUEO
8.-BIBLIOGRAFIA:

Andrs S. Egea

Pgina 1 de 22

1. INTRODUCCIN AL CONCEPTO PROCESO.

El concepto fundamental de todo sistema operativo es el proceso, o abstraccin de
un programa en ejecucin. Todo lo dems gira alrededor de este concepto, por lo
que es muy importante que los diseadores (y estudiantes) de sistemas operativos
aprendan lo antes posible lo que es un proceso.
Cada instante el procesador est ejecutando un solo programa, pero a lo largo de un
segundo puede haber ejecutado diversos programas, dando al usuario una
sensacin de paralelismo. Esta conmutacin rpida del procesador entre diversos
programas se denomina a veces pseudoparalelismo, para distinguirlo del
verdadero paralelismo hardware, que tiene lugar cuando el procesador y varios
dispositivos de E/S estn funcionando al mismo tiempo.

1.1. EL MODELO DE PROCESOS.

En este modelo, los programas que se ejecutan en el computador, incluso a veces el
sistema operativo, se organizan como un conjunto de procesos. Un proceso es un
programa en ejecucin que comprende el valor actual del contador de programa, de
los registros y de las variables.
Lo que en realidad ocurre es que el procesador real conmuta continuamente de un
proceso a otro esta conmutacin entre programas se denomina multiprogramacin.
Al programar procesos no se deben hacer suposiciones a priori de cunto tardar su
ejecucin.
La diferencia entre proceso y programa, aunque sutil, es fundamental. Pongamos
una analoga para esclarecer este aspecto.
Considrese un experto en informtica con aficiones culinarias, que est haciendo
una tarta de cumpleaos para su hija. Para ello, tiene la receta de la tarta y los
ingredientes necesarios en la cocina: harina, huevos, azcar, etc. En esta analoga,
la receta es el programa, o algoritmo expresado en una notacin adecuada; el
experto es el procesador y los ingredientes son los datos de entrada. El proceso es
la actividad del experto de leer la receta, mezclar los ingredientes y cocinar el pastel.
Imaginemos ahora que el hijo del experto entra llorando, diciendo que le ha picado
una avispa. El experto seala por dnde iba en la receta (salva el estado del proceso
actual), coge un libro de primeros auxilios y comienza a seguir las normas que ste
contiene. Vemos aqu al procesador pasando de un proceso (cocinar) a otro de ms
alta prioridad (prestar atencin mdica), cada uno con un programa diferente (receta
de cocina o libro de primeros auxilios). Despus de haber curado el picotazo de la
avispa, el experto en informtica puede seguir con su tarta desde el punto en que la
dej.
La idea bsica es que los procesos ejecutan actividades diversas. Cada proceso
consta de un programa, su entrada, su salida y su estado. Se puede compartir un
procesador entre varios procesos utilizando un algoritmo de planificacin que decida
cundo interrumpir la labor de un proceso y pasar a otro diferente.

Andrs S. Egea

Pgina 2 de 22

2. TIPOS DE PROCESOS.
Existen procesos que ejecutan programas en respuesta a los comandos que escribe
el usuario. Otros procesos forman parte del sistema e implementan diversas labores,
como servir peticiones para realizar funciones sobre ficheros o gestionar el uso de
una unidad de disco. As, si llega una interrupcin del disco, el sistema decide parar
el proceso que estaba en ejecucin en ese instante y ejecutar el proceso del disco,
que estaba bloqueado esperando esta interrupcin. De esta forma, en vez de tener
que pensar en interrupciones, se puede razonar sobre procesos de usuario,
procesos de disco, procesos de terminal, etc., que se encuentran bloqueados
esperando que suceda algo. Una vez ledo el bloque del disco o escrito el carcter
en el terminal, el proceso que estaba esperando ese evento se desbloquea, y a partir
de ese momento est listo para ejecutarse.
Figura 1. Todo el manejo de interrupciones, as como el arranque y parada de los
procesos, estn ocultos dentro del planificador, que es, en realidad, de un tamao
bastante reducido. El resto del sistema operativo est elegantemente estructurado
en forma de procesos..
Figura 1. El nivel inferior de un sistema operativo estructurado en procesos gestiona
las interrupciones y lleva a cabo la planificacin. El resto del sistema consiste en
procesos secuenciales.
0

..................................
PLANIFICADOR

n-2

n-1

2.1.- CARACTERSTICAS
El sistema operativo debe suministrar los servicios necesarios que permitan el
procesamiento concurrente. Bsicamente estos servicios proporcionan los medios
para la realizacin de las siguientes actividades:
a)Ejecucin concurrente de los procesos
b)Sincronizacin entre procesos
c)Comunicacin entre procesos
Adems, el SO debe disponer de algoritmos de gestin y planificacin de procesos
que se encarguen de las siguientes acciones:
1)Decidir qu proceso se ejecutar o tomar el procesador
2)Llevar cuenta de los estados de los procesos, sus prioridades y toda la
restante informacin relevante acerca de ellos.
Dependiendo de la interaccin entre los procesos, stos se clasifican en
independientes, cooperativos y competitivos.
Los procesos independientes no se comunican o sincronizan entre ellos. En un
sistema con un slo procesador, los procesos independientes en sentido estricto no
existen, ya que todos compiten por la posesin del procesador y posiblemente por la
Andrs S. Egea

Pgina 3 de 22

memoria y los dispositivos de E/S. Los procesos cooperativos se comunican y

sincronizan sus actividades para realizar una labor comn. Por ejemplo, en el
computador a bordo de un avin hay procesos encargados de vigilar el funcionamiento de los motores, actualizar los instrumentos de vuelo, procesar las seales
de los instrumentos de navegacin y mantener el rumbo. Todos los procesos
cooperan durante el vuelo del avin, lo que puede requerir frecuentes interacciones
entre todos ellos. Al compartirse los recursos de un computador todos los procesos
compiten entre ellos. El acceso ordenado a estos recursos necesita de la
sincronizacin y a veces tambin de la comunicacin entre los procesos.
En algunos sistemas operativos como en los de tiempo compartido, cada programa
que se pasa a ejecucin, por ejemplo mediante una orden de "ejecutar" dada por el
usuario, se trata como un proceso independiente. Estos procesos generados por el
SO se denominan implcitos. Una vez terminada la ejecucin de los mismos, su
eliminacin tambin la realiza el propio SO. As mismo, el SO proporciona en tiempo
real los servicios que son necesarios para que el usuario pueda definir procesos de
forma explcita. Los programas acceden a estos servicios realizando llamadas al
sistema (system calls).
Al comienzo de la ejecucin del programa principal de un usuario se inicia la
ejecucin de un proceso. A su vez el proceso podra crear nuevos procesos. En este
caso, el proceso que crea otro nuevo se denomina proceso padre (parent process),
y el proceso creado se denomina proceso hijo (child process). Una vez creado un
proceso hijo, la ejecucin de padre e hijo transcurre de manera concurrente. De esta
forma, se puede crear una jerarqua arborescente de procesos, en la que un padre
puede tener varios hijos y stos pueden tener otros hijos, etc., pero donde cada hijo
slo tiene un padre.

3. COMUNICACIN ENTRE PROCESOS.

Frecuentemente, los procesos necesitan comunicarse entre s. As, para leer de un
fichero, los procesos de usuario han de decirle lo que desean al proceso que
gestiona los ficheros. Este a su vez, debe pedirle al proceso de disco que lea los
bloques necesarios. En resumen, se necesita que los procesos se comuniquen entre
s, a ser posible con un mecanismo bien estructurado y no por medio de
interrupciones.

3.1. CONDICIONES DE CARRERA.

En algunos sistemas operativos, los procesos cooperan entre s suelen compartir un
rea comn de la que leen o en la que escriben.
Estas situaciones, en que dos o ms procesos leen o escriben en un rea
compartida y el resultado final depende de los instantes de ejecucin de cada uno,
se denominan condiciones de carrera. La puesta a punto de programas con
condiciones de carrera no es nada divertida. Casi todas las pruebas suelen ir bien,
pero, de cuando en cuando, pasa algo raro e inexplicable. P.e. cuando dos procesos
aceden al mismo tiempo sobre un recurso , entrando los dos , meclando informacin.
Andrs S. Egea

Pgina 4 de 22

3.2 SECCIONES CRITICAS.

Cmo evitar que surja condiciones de carrera?. El problema se resuelve sin ms
que impedir que haya ms de un proceso leyendo o escribiendo simultneamente
los datos compartidos, necesitamos exclusin mutua, que no es sino una forma de
garantizar que mientras un proceso est usando una variable o un fichero
compartidos, los otros procesos no podrn hacerlo.
La seleccin de las operaciones primitivas adecuadas para garantizar la exclusin
mutua es una decisin primordial en el diseo de un sistema operativo, as que la
examinaremos detenidamente en los apartados siguientes:
El problema de evitar condiciones de carrera se puede formular de una forma
abstracta. Durante una parte de su tiempo, los procesos llevan a cabo actividades
internas que no pueden conducir a condiciones de carrera. Sin embargo, a veces los
procesos pueden acceder a ficheros o reas de memoria compartidas, o realizar
otras actividades que pueden llegar a producir carreras. La parte del programa que
accede a la memoria compartida se denomina seccin crtica. Si pudiramos arreglar
las cosas de manera que no hubiera nunca simultneamente dos procesos dentro de
sus secciones crticas, se podran evitar las condiciones de carrera.
Aunque este requisito eliminara las condiciones de carrera, no es en s mismo
suficiente para que los procesos paralelos puedan cooperar correcta y
eficientemente empleando datos comunes. Una solucin apropiada debera cumplir
las cuatro condiciones siguientes:
1. Que no haya en ningn momento dos procesos dentro de sus respectivas
secciones crticas.
2. Que no se hagan suposiciones a priori sobre las velocidades relativas de los
procesos o el nmero de procesadores disponibles.
3. Que ningn proceso que est fuera de su seccin crtica pueda bloquear a otros.
4. Que ningn proceso tenga que esperar un intervalo de tiempo arbitrariamente
grande para entrar en su seccin crtica.

3.3. EXCLUSIN MUTUA

3.3.1. EXCLUSIN CON ESPERA ACTIVA.
Garantiza la exclusin mutua, que hacen que mientras un proceso est dentro de su
regin crtica actualizando la memoria compartida, el resto de los procesos no
puedan entrar en sus regiones crticas y se quedan solicitando la entrada.

3.3.2. PROHIBICIN DE LAS INTERRUPCIONES.

La solucin ms sencilla es que cada proceso prohiba todas las interrupciones justo
antes de entrar en su regin crtica y las permita de nuevo justo antes de salir. El
Andrs S. Egea

Pgina 5 de 22

prohibir interrupciones hace que no pueda conmutarse el procesador a otro proceso,

despus de prohibir las interrupciones, un proceso puede examinar y cambiar la
memoria compartida sin tener que preocuparse de que otro proceso pueda estar
haciendo lo mismo.
Si un proceso prohibiera las interrupciones y no las permitiera de nuevo, sera el fin
del sistema. Adems, si el computador tuviera dos o ms procesadores, la
desactivacin de las interrupciones slo afectara al procesador que ejecut la
instruccin.
Sin embargo, a veces es conveniente que el propio ncleo prohiba las interrupciones
mientras est actualizando sus variables o listas.
La conclusin es, pues, que la prohibicin de interrupciones es un mecanismo
adecuado para garantizar la exclusin mutua dentro del ncleo, pero poco
recomendable para procesos de usuario.

3.3.3. VARIABLES CERROJO.

Una variable (cerrojo) compartida, cuyo valor inicial es 0. Cuando un proceso quiera
entrar en su regin critica comprobar el valor del cerrojo. Si es 0, el proceso lo
pondr a 1 y entrar en la regin crtica; si ya es 1, el proceso esperar hasta que el
cerrojo vuelva a valer 0.
Por desgracia, este algoritmo contiene un error garrafal , si un proceso lee la variable
y entra , entre tanto otro proceso ha podido entrar.
Quizs piense que el problema se podra evitar leyendo primero el valor del cerrojo y
volvindolo a comprobar de nuevo justo antes de escribirlo. La realidad es que esto
tampoco funciona. Condicin de carrera se produce igualmente si el segundo
proceso modifica el cerrojo justo despus de que el primer proceso haya
comprobado su valor por segunda vez.

3.3.4. ALTERNANCIA ESTRICTA.

Tener una variable entera, turno, con valor inicial 0, que lleva la cuenta de a quin le
toca el turno de entrar en la regin crtica y utilizar la memoria compartida. Al
principio, el proceso 1 lee turno, ve que vale 0, as que se mete en un bucle donde
comprueba continuamente el valor de turno hasta que valga 1 . La comprobacin
continua del valor de una variable hasta que adquiera un valor determinado se
denomina espera activa. Dado que desperdicia tiempo de procesador, debera
evitarse en lo posible.
Cuando el proceso 0 sale de su seccin crtica, pone turno a 1, con lo que el proceso
1 puede ahora entrar en la suya. Supongamos que el proceso 1 termina rpidamente
de ejecutar su seccin crtica, de forma que ambos procesos se encuentran
ejecutando sus secciones no crticas y la variable turno tiene el valor 0. A
continuacin, el proceso 0 ejecuta rpidamente todo el bucle, llegando a su seccin
no crtica con la variable turno puesta a 1. Seguidamente, el proceso 0 termina su
seccin no crtica y llega de nuevo al principio de su bucle. Desafortunadamente, no
se le deja entrar en su seccin crtica, porque turno vale 1 y el proceso 1 est
todava ejecutando su seccin no crtica. Dicho de otro modo, repartir turnos no es
Andrs S. Egea

Pgina 6 de 22

una buena idea en los procesos mucho ms lentos que el otros.

Esta situacin vulnera la condicin 3 que enunciamos al principio: el proceso 0
resulta bloqueado por otro proceso que no est en su seccin crtica.

3.3.5. LA SOLUCIN DE PETERSON.

La solucin es bastante complicada, as que nunca se usa en la prctica,
Antes de utilizar las variables compartidas, un proceso llama a entrar-en-regin,
pasndose como parmetro su nmero de proceso, 0 1. Si hace falta, esta llamada
bloquear al proceso hasta que no haya problema para entrar en la regin crtica.
Una vez que un proceso sale de su regin crtica, llama a salir - de - regin, lo que
permite que los otros procesos puedan acceder a las variables comunes si lo
desean.
Considrese ahora el caso de que ambos procesos llamen a entrar-en_region casi
simultneamente. Ambos asignarn a turno su nmero de proceso respectivo. La
ltima de estas asignaciones es la que Prevalece, la otra se pierde. Supongamos
que el proceso 1 es el ltimo en realizar la asignacin, de forma que turno tiene el
valor 1.

3.3.6. ALGORITMO DE DEKKER

La solucin al problema de la exclusin mutua que sigue se atribuye al matemtico
holands T. Dekker, y fue presentada por Dijkstra en 1968. Se utiliza, al igual que en
la solucin de Peterson, una variable turno. Ahora la variable sirve para establecer la
prioridad relativa de los dos procesos y su actualizacin se realiza en la seccin
crtica, lo que evita que pueda haber interferencias entre los procesos.
El programa se inicia con el valor de turno igual a 1, lo que da prioridad al proceso
Pl. Si ambos procesos piden a la vez el acceso a su seccin crtica, ponen en activo
sus respectivos indicadores y comprueban si el indicador del otro est activado.
Ambos encuentran que s, por lo que pasan a evaluar el turno. El segundo se
encuentra con que no es su turno, desactiva su indicador y se queda en espera de
que lo sea. Pl comprueba que si es el suyo y pasa a valorar el estado del indicador
de P2, entrar en su seccin crtica y dar el turno a P2 antes de desactivar su
indicador. Esto permite que el proceso P2 gane el acceso a su seccin crtica
aunque el proceso Pl haga una nueva solicitud de entrar a la regin crtica
inmediatamente despus de desactivar su indicador.

3.3.7 DORMIR Y DESPERTAR.

La solucin de Peterson adolecen del efecto de tener que utilizar espera activa.
Este mecanismo no slo malgasta tiempo del procesador, sino que tambin puede
producir efectos inesperados.
Examinemos ahora algunas primitivas de comunicacin entre procesos que, en lugar
de malgastar tiempo de procesador cuando un proceso no puede entrar en su regin
crtica, bloquean la ejecucin del mismo. Una de las parejas ms simples de
Andrs S. Egea

Pgina 7 de 22

primitivas son DORMIR (sleep) y DESPERTAR (wakeup). DORMIR es una llamada

al sistema que bloquea al llamador, es decir, suspende su ejecucin hasta que otro
proceso lo despierta. La llamada DESPERTAR tiene como parmetro el proceso que
se debe despertar.
El problema de productor-consumidor (buffer finito), el productor deja informacin
en el buffer, y el consumidor la retira. Los problemas comienzan cuando el productor
quiere dejar algo en el buffer, pero ste ya est lleno. La solucin es mandar a
dormir al productor y despertarlo slo cuando el consumidor haya retirado uno o ms
elementos. Debe enviarse a dormir al consumidor cuando trate de retirar un
elemento del buffer, y ste est vaco. Ms tarde, cuando el productor deje uno o
ms elementos en el buffer, despertar al consumidor.
Para llevar la cuenta del nmero de elementos en el buffer, necesitaremos una
variable, cuenta. Si N es el mximo nmero de elementos que caben en el buffer, el
programa del productor deber comprobar primero si cuenta es igual a N. En caso
afirmativo, el productor se ir a dormir; en caso negativo, el productor aadir un
elemento e incrementar el valor de cuenta.
El programa del consumidor es anlogo: primero comprobar si cuenta es igual a 0.
En caso afirmativo, se ir a dormir; si es distinta de cero, retirar un elemento y
decrementara el contador.

3.3.8 SEMFOROS.
E. W. Dijkstra (1965), se le ocurri utilizar una variable entera para contar el nmero
de seales de despertar puestas "en conserva" para uso futuro. Propuso para ello un
nuevo tipo de variable, llamada semforo. Esta podra valer 0, en caso de que no
hubiera ningn despertar en conserva, o algn valor positivo, si hubiera uno o ms
pendientes.
Dijkstra propuso dos operaciones, BAJAR y SUBIR, que eran generalizaciones de
DORMIR y DESPERTAR, respectivamente. La operacin BAJAR aplicada a un
semforo comprueba el valor del mismo; si es mayor que 0, decrementa su valor
(.e., se consume una de las seales de despertar en conserva) y se contina la
ejecucin, si el valor del semforo es 0, el proceso se pone a dormir. Las
operaciones se realizan todas como una sola accin atmica, invisible. Se
garantiza que, una vez que ha comenzado una operacin en un semforo, ningn
otro proceso podr acceder al mismo hasta que la operacin haya terminado o se
haya bloqueado.
La operacin SUBIR incrementa el valor del semforo correspondiente. As, despus
de una operacin de SUBIR habr un proceso menos durmiendo en l.
Los procesos no se bloquean nunca en una operacin de SUBIR, de la misma forma
que en el modelo anterior los procesos nunca se bloquean en una operacin
DESPERTAR.

3.3.9. MONITORES.
Para simplificar la escritura de programas correctos, Hoare (1.974) y Brinch Hasen
Andrs S. Egea

Pgina 8 de 22

(1.975) propusieron una primitiva de sincronizacin de ms alto nivel, llamada

monitor. Un monitor es un conjunto de procedimientos, variables y estructuras de
datos agrupados en un tipo especial de mdulo o paquete.
Slo un proceso puede estar activo dentro de un monitor en un instante dado. Los
monitores sabe que son algo especial y traduce las llamadas a procedimientos del
monitor de forma distinta a otras llamadas a procedimiento. Cuando las primeras
instrucciones del procedimiento comprueban si hay en ese momento algn otro
proceso activo dentro del monitor. En caso negativo, el proceso puede entrar en el
monitor, pero en caso afirmativo se suspende al proceso llamador hasta que el otro
haya salido del monitor.
La implementacin de exclusin mutua en entradas a monitores es responsabilidad
del compilador. Dado que es el compilador, no el programador, el que se encarga de
implementar la exclusin mutua, es ms improbables que se cometan errores.
Se necesita tambin un mecanismo para bloquear un proceso cuando no pueda
continuar ejecutndose. cmo habra que bloquear al productor cuando se
encuentre el buffer lleno?.
Esto se soluciona introduciendo las variables condicin, junto con dos operaciones
aplicables sobre ellas, ESPERAR y DARPASO. Cuando un procedimiento de un
monitor se da cuenta de que no puede continuar, realiza un ESPERAR sobre una
determinada variable condicin, por ejemplo, lleno. Esto no slo hace que el proceso
llamador se bloque, sino que tambin permite que pueda entrar en el monitor otro
proceso que se hubiera bloqueado al intentar entrar en el mismo.
Este otro proceso, que podra ser, por ejemplo, el consumidor podra despertar a su
compaero por medio de una llamada DARPASO sobre la variable condicin en la
que el compaero se qued bloqueado. Un proceso que ejecuta una operacin de
DARPASO debe abandonar el monitor inmediatamente. Si hay varios procesos
esperando en una variable condicin sobre la que se realiza una operacin
DARPASO slo se despierta una de ellos, a eleccin del planificador. Ni C ni Pascal,
ni otros muchos lenguajes de programacin tienen monitores, as que no se puede
pretender que sus compiladores impongan mecanismos de exclusin mutua.

3.3.10 MENSAJES
Los mensajes proporcionan una solucin al problema de la concurrencia de
procesos que integra la sincronizacin y la comunicacin entre ellos y resulta
adecuado tanto para sistemas centralizados como para distribuidos. Esto hace que
se incluyan prcticamente en todos los sistemas operativos modernos y que en
muchos de ellos se utilicen como base para todas las comunicaciones del sistema,
tanto dentro del computador como con otros computadores.
La comunicacin mediante mensajes necesita siempre de un proceso emisor y de
uno receptor y la informacin que debe intercambiarse. Las operaciones bsicas
para una comunicacin mediante mensajes que proporciona todo sistema
operativo son: enviar(mensaje) y recibir(mensaje). Las acciones de transmisin de
informacin y de sincronizacin se ven como actividades inseparables.
Andrs S. Egea

Pgina 9 de 22

La comunicacin por mensajes requiere que se establezca un enlace entre el

receptor y el emisor, la forma del mismo puede variar mucho de sistema a sistema.
Aspectos importantes a tener en cuenta en los enlaces son:
a)
b)
c)

Cmo y cuntos enlaces se pueden establecer entre los procesos

La capacidad de mensajes del enlace
El tipo de los mensajes.

su implementacin vara dependiendo de los tres aspectos siguientes:

1)
2)
3)

El modo de nombrar los procesos.

El modelo de sincronizacin.
Almacenamiento y estructura del mensaje.

3.3.10.1.

Modos de nombrar a los mensajes.

El proceso de denominacin de las tareas para la comunicacin por mensajes se

puede realizar de dos formas distintas: directa e indirectamente.
Comunicacin directa
En esta forma de comunicacin ambos procesos, el que enva y el que recibe,
nombran de forma explcita al proceso con el que se comunican. Las operaciones de
enviar y recibir toman la forma:
enviar(Q, mensaje): enva un mensaje al proceso Q
recibir(P, mensaje): recibe un mensaje del proceso P
Comunicacin indirecta
En este mtodo los mensajes se envan y reciben a travs de una entidad intermedia
que recibe el nombre de buzn o puerto. Como su nombre indica, un buzn es un
objeto en el que los procesos dejan mensajes y del cual pueden tomarse por otros
procesos. Ofrecen una mayor versatilidad que en el caso del nombramiento directo,
ya que permiten comunicacin de uno a uno, de uno a muchos, de muchos a uno y
de muchos a muchos.
Cada buzn tiene un identificador que lo distingue. En este caso las operaciones
bsicas de comunicacin tienen la forma:
enviar (buznA, mensaje): enva un mensaje al buzn A
recibir (buznA, mensaje): recibe un mensaje del buzn A.
Adems de las operaciones bsicas mencionadas, los sistemas operativos suelen
proporcionar otras operaciones adicionales como las de crear y eliminar buzones.

3.3.10.2

Modelos de sincronizacin

Las diferencias en los modelos usados para la sincronizacin de los procesos se

debe a las distintas formas que puede adoptar la operacin de envo del mensaje.
Andrs S. Egea

Pgina 10 de 22

a)Sncrona. El proceso que enva slo prosigue su tarea cuando el mensaje

ha sido recibido.
b)Asncrona. El proceso que enva un mensaje sigue su ejecucin sin
preocuparse de si el mensaje se recibe o no.
c)Invocacin remota. El proceso que enva el mensaje slo prosigue su
ejecucin cuando ha recibido una respuesta del receptor.

3.3.10.3

Almacenamiento y estructura del mensaje

En la transferencia de informacin en un enlace se deben tener en cuenta la forma

en la que este se produce y la capacidad o nmero de mensajes que admite. A su
vez, el intercambio de informacin se puede realizar de dos formas: por valor o por
referencia.
En la transferencia por valor se realiza una copia del mensaje desde el espacio de
direcciones del emisor al espacio de direcciones del receptor, mientras que en la
transferencia por referencia se pasa slo un puntero al mensaje. La transferencia por
valor tiene la ventaja de que mantiene desacoplada la informacin que manejan el
emisor y el receptor, lo que proporciona mayor seguridad en la integridad de la
informacin. Tiene, sin embargo, los inconvenientes del gasto de memoria y del
tiempo que implica la copia, que adems se suelen ver incrementados por el uso de
una memoria intermedia. Estos inconvenientes son justamente las ventajas de la
transmisin por referencia, que tiene como aspecto negativo el necesitar
mecanismos adicionales de seguridad para compartir la informacin entre los
procesos. El mtodo de sincronizacin de la invocacin remota utiliza
necesariamente la transferencia por valor, mientras que los mtodos sncrono y
asncrono pueden utilizar ambos modos.
Atendiendo a la estructura de los mensajes estos se pueden considerar divididos en
tres tipos:
a)
b)
c)

Longitud fija
Longitud variable
De tipo definido

4. GESTIN DE PROCESOS
Para implementar el modelo de procesos, el sistema operativo utiliza una tabla
(vector de registros), llamada tabla de procesos, que tiene una posicin por cada
proceso. Esta posicin contiene informacin sobre el estado del proceso, su
contador de programa, el puntero de pila, la memoria asignada, el estado de sus
ficheros abiertos, informacin relativa a su planificacin y a su utilizacin de los
recursos, ... ; en resumen, toda la informacin que hay que salvar cuando el proceso
pasa del estado en ejecucin al estado listo para ejecutarse. Esta informacin
permitir activar de nuevo el proceso como si nunca se hubiera parado.
Vectores de interrupciones, cada una de las cuales est relacionada con una clase
de dispositivos de E/S.
Andrs S. Egea

Pgina 11 de 22

Supongamos que cuando llega una interrupcin del disco se est ejecutando el
proceso de usuario. El mecanismo hardware de interrupcin salvar
automticamente en la pila el contador de programa, la palabra de estado de
programa, y, quizs, uno o ms registros. El computador ejecutar, seguidamente,
un salto a la direccin de memoria especificada en el vector de interrupciones de
disco, Esto es todo lo que hace el hardware. A partir de ese momento, el software se
encarga del resto.
Lo primero que hace el procedimiento de servicio de la interrupcin es salvar todos
los registros en la posicin de la tabla de procesos correspondientes al proceso
actual. Con objeto de poderlos recuperar con rapidez, el nmero de este proceso y
un puntero a su registro en la tabla de procesos se almacenan en variables globales.
A continuacin, se recupera de la pila la informacin que la interrupcin ha
almacenado all, y se carga el puntero de pila con un nuevo valor para que apunte a
una pila auxiliar utilizada por el manejador de procesos.
Cuando esta rutina termina, llama a un procedimiento en C para que haga el resto.
El paso siguiente consiste en elaborar un menaje para enviarlo al proceso de disco,
que estar bloqueado esperndolo. El mensaje indica que se ha producido una
interrupcin.
A continuacin, se cambia el estado del proceso de disco de bloqueado a listo para
ejecutarse, y se llama al planificador. Este asigna prioridades distintas a los
diferentes tipos de procesos, lo que permite dar servicio ms rpido a los
manejadores de dispositivos de E/S que a los procesos de usuario. Si un proceso
de disco fuera ahora el proceso ejecutable de ms alta prioridad, se le asignara el
procesador. En cambio, si el proceso que ha sido interrumpido es de igual o mayor
prioridad, se le ceder el procesador de nuevo, de modo que el proceso de disco
tendr que esperar todava un rato.
En cualquier caso, el procedimiento C devuelve finalmente control, y el cdigo
ensamblador carga los registros generales y el mapa de memoria del proceso que va
a estar ahora en ejecucin y le cede el procesador.
1. El hardware mete en la pila el contador de programa, etc.
2. El hardware carga un nuevo contador de programa desde el vector de
interrupciones.
3. Un procedimiento en ensamblador salva los registros en tabla.
4. Otro procedimiento en ensamblador cambia el valor del puntero de pila.
5. Un procedimiento en C cambia el estado del proceso de servicio a listo para
ejecutarse
6. El planificador escoge el siguiente proceso a ejecutar.
7. Un procedimiento en C pasa control al cdigo ensamblador.
Andrs S. Egea

Pgina 12 de 22

8. Un procedimiento en ensamblador arranca el proceso actual. (el que le toque).

Esquema de lo que hacen los niveles inferiores del sistema operativo cuando ocurre
una interrupcin.

5. ESTADO DE LOS PROCESOS.

Aunque los procesos son entidades independientes, dotadas de contador de
programa y estado interno propios, suelen tener que interaccionar entre s. Un
proceso puede generar un resultado de salida que otro tenga que usar como
entrada.
El bloqueo de un proceso suele suceder porque, desde un punto de vista lgico, su
ejecucin no puede continuar, normalmente porque ha de esperar datos de entrada
que todava no estn disponibles. Un proceso se puede tambin parar, aunque
conceptualmente est listo para ejecutarse, porque el sistema operativo decida
asignar el procesador a otro proceso durante un cierto tiempo. Estas dos situaciones
son completamente diferentes.
1. En ejecucin (usando el procesador).
2. Bloqueado (sin poder hacer nada hasta que ocurra un evento externo).
3. Listo (ejecutable; parado temporalmente para que pueda ejecutarse otro proceso).
Figura. Los procesos pueden estar en tres estados: en ejecucin, bloqueados o
listos para ejecutarse
Se puede ver que hay cuatro transiciones posibles entre los diversos estados. La
transaccin 1 ocurre cuando un proceso descubre que no puede continuar. En
algunos sistemas, el proceso debe ejecutar una llamada, BLOCK, para pasar al
estado de bloqueado. En otros sistemas, cuando un proceso lee de un fichero , y no
hay ningn dato a la entrada, pasa automticamente al estado de bloqueado.
El planificador de procesos, que es parte del sistema operativo, lleva a cabo las
transiciones 2 y 3, sin que los procesos ni siquiera se enteren. La transicin 2
sucede cuando el planificador considera que el proceso en ejecucin ya ha
dispuesto del procesador durante suficiente tiempo, y decide que es el momento de
asignarlo a otro proceso. La transicin 3 tiene lugar cuando el resto de los procesos
ha ocupado el procesador durante el tiempo asignado y es hora de que el primer
proceso pueda continuar ejecutndose. La teora de la planificacin, que consiste en
decidir qu procesos deberan ejecutarse y durante cunto tiempo, es fundamental
en sistemas operativos.
Cuando sucede el evento externo que el proceso estaba esperando, tiene lugar la
transicin 4. Si no hay en ese momento ningn proceso en ejecucin, se llevar a
cabo inmediatamente la transicin 3 y el proceso empezar a ejecutarse. En caso
contrario, el proceso deber esperar en estado listo para ejecutarse durante un rato,
hasta que est disponible el procesador.

Andrs S. Egea

Pgina 13 de 22

El programa es
selecionado por el
planificador
de
trabajos

No cabe en M.P.
,procesos
en
ejecucin
concurrentes.

DISCO

retenido
en cola

intercambio

Le llega
turno

Pide E/S

EN
EJECUCI
Se le acaba el
Quantum

Fin E/S

LISTO

BLOQUEAD
O (espera)

MEMORIA PRINCIPAL

6. PLANIFICACIN DE PROCESOS.
Cuando hay dos o ms procesos listos para ejecucin, el sistema operativo debe
decidir cul se ha de ejecutar primero. La parte del sistema operativo encargada de
tomar esta decisin es el planificador, y el algoritmo o que utiliza se llama algoritmo
de planificacin. En los viejos tiempos de los sistemas de procesamiento por lotes, el
algoritmo de planificacin era bien simple: ejecutar el siguiente trabajo de la cinta. La
situacin se complic cuando llegaron los sistemas multiusuario en tiempo
compartido, que incluso llegaban a realizar procesamientos por lotes como actividad
en segundo plano.
A la hora de juzgar si un algoritmo de planificacin es bueno, se pueden aplicar
varios criterios, a saber:
1. Equidad: que se asigne el procesador a cada de forma equitativa.
2. Eficiencia: que se mantenga ocupado el procesador el 100 por cien del tiempo.
3.Tiempo de respuesta: que se minimice el tiempo de respuesta para usuarios
4.Tiempo de procesos global: que se minimice el tiempo que han de esperar los
usuarios de trabajos por lotes para obtener resultados a la salida.
5. Rendimiento: que se maximice el nmero de trabajos procesador en cada unidad
de tiempo.
Algunos de estos objetivos son contradictorios. Se puede demostrar que cualquier
Andrs S. Egea

Pgina 14 de 22

algoritmo de planificacin que favorezca un tipo de trabajos perjudicar a otro.

Un problema adicional para los planificadores se deriva del hecho de que el
comportamiento de los procesos es nico e impredecible. Para asegurar se de que
ningn proceso monopolizar el procesador durante mucho tiempo, caso todos los
computadores tiene un temporizador hardware, o reloj, que produce interrupciones
peridicas. ste suele tener una frecuencia de 50 60 ciclos por segundos (Hercios,
abreviadamente Hz), aunque en muchos computadores el sistema operativo puede
asignar cualquier valor a la frecuencia del temporizador. Con cada interrupcin de
reloj, el sistema operativo recupera el control y decide si debe dejar que el proceso
actual contina ejecutndose, o si, por el contrario, ste ya ha utilizado el procesador
durante un tiempo suficientemente largo y, por lo tanto, es momento de suspender
su ejecucin y ceder el uso del procesador a otro proceso.
Este mecanismo se llama planificacin expulsiva, a diferencia del mtodo de
ejecucin hasta terminacin.

6.1 Planificacin por turno rotatorio.

A cada proceso se le asigna un intervalo de tiempo, llamndose quantum , durante el
cual puede ejecutarse. Si el proceso est todava ejecutndose al final del quantum,
se le expulsa del procesador, que se concede a otro proceso. Por supuesto, si antes
de que expire el quantum, el proceso ya est bloqueado o ha terminado, el
procesador se conmuta en el momento del bloqueo. La conmutacin entre procesos
exige algo de tiempo, porque debe realizar ciertas funciones, como cargar y salvar
los registros y mapas de memoria, actualizar diversas tablas y listas, etc. asignar un
valor muy pequeo al quantum aumenta demasiado el nmero de cambios de
proceso y disminuye la eficacia del procesador, pero darle un valor demasiado
grande empobrece los tiempos de respuesta a peticiones interactivas cortas. Un
valor del quantum de unos 100 milisegundos suele ser un compromiso razonable.

6.2 Planificacin por prioridad.

La planificacin por prioridad deriva de la necesidad de tomar en consideracin los
factores externos. La idea bsica es simple: a cada proceso se le asigna una
prioridad, de forma que siempre se concede el procesador al proceso ejecutable de
ms alta prioridad.
Para evitar que los procesos de alta prioridad se ejecutan por tiempo indefinido, el
planificador puede decrementar la prioridad del proceso que est ejecutndose en
cada momento con cada pulso de reloj.
La asignacin de prioridades a procesos se puede realizar de forma esttica o
dinmica.

6.3 Listas de espera mltiples.

Los procesos en la categora superior se ejecutan durante un quantum . Los
procesos en la siguiente categora se ejecutan durante dos quantum, los de la
Andrs S. Egea

Pgina 15 de 22

siguiente en cuatro, y as sucesivamente. Cada vez que un procesos utilizaba todos

los quantum que le correspondan, se le pasaba inmediatamente a la categora
inferior.
Como ejemplo, considrese un proceso que deba ejecutarse durante 100 quantum.
Se lo dejara durante un quantum, y se le quitara el procesador. La siguientes vez
se le dejara ejecutar durante dos quantum, y se le quitara el procesador. En
ejecuciones sucesivas tendra 4,8,16,32 y 64 quantum , si bien del ltimo slo
utilizara 37. De esta manera, slo haran falta 7 transferencias a disco, en lugar de
las 100 necesarias con un algoritmo por turno rotatorio puro.

6.4 Prioridad al ms corto.

Un algoritmo especialmente indicado para sistemas por lotes en los que se conoce
de antemano el tiempo de ejecucin. Con una planificacin al ms corto. El algoritmo
de prioridad al ms corto es ptimo.

7.- INTERBLOQUEO
El error ms serio que puede ocurrir en entornos concurrentes es el conocido como
interbloqueo, que consiste en que dos o ms procesos entran en un estado que
imposibilita a cualquiera de ellos salir del estado en que se encuentra. A dicha
situacin se llega porque cada proceso adquiere algn recurso necesario para su
operacin a la vez que espera a que se liberen otros recursos que retienen otros
procesos, llegndose a una situacin que hace imposible que ninguno de ellos
pueda continuar.
Por ejemplo, supongamos que se tienen dos procesos Pl y P2 que desean acceder a
dos recurso (por ejemplo, impresora y disco) a los que slo puede acceder un
proceso cada vez. Suponemos que los recursos estn protegidos por los semforos
S1 y S2. Si los procesos acceden a los recursos en el mismo orden no hay ningn
problema.
El primer proceso que toma S1 tambin toma S2 y posteriormente libera los recursos
en orden inverso a como se tomaron y permite al otro proceso acceder a ellos. Sin
embargo, si uno de los procesos desea utilizar los recursos en orden inverso, podra
ocurrir que Pl tomara el primer recurso (semforo S) y P2 el segundo recurso
(semforo S2) y se quedarn ambos en espera de que el otro liberara el recurso que
posee.
Este error no ocurre con demasiada frecuencia, pero sus consecuencias suelen ser
devastadoras. En algunas ocasiones puede resultar fcil darse cuenta de la
posibilidad de que ocurra el interbloqueo, pero la mayora de las veces resulta
realmente complicado detectarlo.

7.1. Caracterizacin del interbloqueo

Para que se de una situacin de interbloqueo se deben cumplir de forma simultnea
las cuatro condiciones siguientes:
1)Exclusin mutua. Los procesos utilizan de forma exclusiva los recursos que han
Andrs S. Egea

Pgina 16 de 22

adquirido. Si otro proceso pide el recurso debe esperar a que este sea liberado.
2)Retencin y espera. Los procesos retienen los procesos que han adquirido
mientras esperan para adquirir otros recursos que estn siendo retenidos por otros
procesos.
3)No existencia de expropiacin. Los recursos no se pueden quitar a los procesos
que los tienen; su liberacin se produce voluntariamente una vez que los procesos
han finalizado su tarea con ellos.
4)Espera circular. Existe una cadena circular de procesos en la que cada uno
retiene al menos un recurso que se solicita por el siguiente proceso de la cadena.
La condicin de espera circular implica la condicin de retencin y espera, sin
embargo, resulta til considerar ambas condiciones por separado.

7.2. Prevencin y Evitacin de interbloqueo

Existen dos formas principales de tratar el problema del interbloqueo. Una de ellas
consiste en evitar que se entre en esa situacin, y la otra en permitir que se pueda
entrar y recuperarse de ella. Hay dos mtodos para evitar que ocurran: prevencin
de los interbloqueos y evitacin de los interbloqueos.

Prevencin de interbloqueos
En este mtodo se trata de evitar cualquier posibilidad que pueda llevar a la
situacin de interbloqueo. Es posiblemente el mtodo ms utilizado, pero puede
llevar a una pobre utilizacin de los recursos. Como las cuatro condiciones son
necesarias para que se produzca el interbloqueo basta con evitar una de ellas para
que no se produzca.
La condicin de exclusin mutua se debe mantener ya que es necesario mantener
recursos que no se puedan compartir, por ejemplo una impresora. Examinamos el
resto de las condiciones de forma separada.
Retencin y espera
Para que no se cumpla esta condicin se debe garantizar que un proceso que posee
un recurso no pueda pedir otro. Una manera de proceder es haciendo que la peticin
de todos los recursos que necesita un proceso se realice bajo la premisa de todos o
ninguno. Si el conjunto completo de recursos necesitados por el proceso estn
disponibles se le concede y en caso contrario, se suspende en espera de que todos
lo estn. Dicha espera se debe realizar sin que se posea ningn recurso. Este modo
de proceder no resulta adecuado si, por ejemplo, va a haber recursos que slo se
van a utilizar al final de la ejecucin del proceso y que sin embargo, se mantienen
retenidos mientras se hace uso de otros. Para evitarlo se puede proceder pidiendo
conjuntos de recursos con la condicin de o todos o ninguno, pero slo cuando no se
disponga de otros. De este modo, si, por ejemplo, se va a copiar de dos discos a una
impresora, se puede pedir la impresora y uno de los discos, despus se liberan y a
continuacin se pide el otro disco y la impresora. De este modo uno de los discos no
est retenido mientras se est imprimiendo del otro.
Andrs S. Egea

Pgina 17 de 22

El mtodo plantea dos problemas:

1)Pobre uso de los recursos, ya que puede haber recursos retenidos que no estn
en uso y otros que, aunque no estn retenidos, no se pueden asignar por ser
requeridos junto con otros que silo estn.
2)Puede resultar difcil que un conjunto de recursos se encuentren disponibles a la
vez, lo que puede producir una espera indefinida del proceso que los necesita.
No existencia de expropiacin
Esta condicin se puede evitar, lgicamente, permitiendo la expropiacin. Para
conseguirlo se puede actuar de la forma siguiente. Si un proceso que tiene uno o
ms recursos solicita otro ste le es concedido si est disponible. En el caso de que
el nuevo recurso solicitado est en uso, el proceso que lo reclama debe esperar y
permite que los recursos de que dispone se puedan expropiar. De forma implcita el
proceso libera los recursos de que ya dispone y se aaden a la lista de recursos
disponibles y a la vez, a la lista de recursos solicitado por el proceso que los acaba
de liberar. El proceso slo se puede volver a activar cuando pueda ganar el acceso a
todos los recursos que necesita.
Es posible tambin la siguiente estrategia. Si un proceso solicita algunos recursos
primero comprueba que estn libres. Si es as se le asignan. Si no estn libres se
mira si estn asignados a otros procesos que estn esperando, en cuyo caso se
expropian y pasan al proceso que puede entrar en ejecucin disponiendo de
aquellos que se encuentran libres o expropiados. Si hay algn recurso que no est
libre o que no puede ser expropiado, el proceso se suspende y no puede volver a
ejecucin hasta que no disponga de todos los recursos.
El mtodo tiene el inconveniente de que puede llevar a que haya procesos que se
vean relegados durante un tiempo excesivamente grande. Se suele aplicar con
aquellos recursos que pueden ser fcilmente salvados y restaurados, tales como
posiciones de memoria o registros de la UPC.

Espera circular
Para que esta condicin no se produzca se ordenan los recursos asignndoles a
cada tipo de ellos un nmero entero y se impone que se pidan en orden ascendente.
Adems, las peticiones de todos los recursos perteneciente a un mismo tipo deben
realizarse con una nica peticin y no incrementalmente. Por ejemplo, inicialmente
los procesos pueden pedir cualquier recurso; si el proceso Pl pide el recurso con
nmero de orden 3, a continuacin slo puede pedir recursos con nmero de orden
superior a 3. Si desea pedir a la vez dos recursos siempre deber pedir primero el
recurso con menor nmero de orden.
Con esta estrategia no se puede producir la espera circular, ya que un proceso que
posea un recurso de un tipo no puede esperar a ningn otro proceso que est
esperando un recurso del mismo tipo o con un orden inferior.
Andrs S. Egea

Pgina 18 de 22

El mtodo tiene la desventaja evidente de que los recursos no se piden en el orden

que se necesitan, sino en el que se ha establecido. Aquellos procesos que necesiten
los recursos en un orden distinto al especificado pueden verse obligados a pedir los
recursos antes de necesitarlos acaparndolos innecesariamente.

Evitacin de los interbloqueos

El objetivo de este mtodo es imponer condiciones menos restrictivas que en el
mtodo de la prevencin para conseguir un mejor uso de los recursos. No se
pretende evitar toda la casustica de que ocurra un interbloqueo, sino que cuando se
vislumbra la posibilidad de que puede ocurrir un interbloqueo sta se soslaya.
Normalmente esto se consigue haciendo que se considere el caso de que se
produzca un bloqueo cada vez que se asigna un recurso. Si se prev esta
posibilidad el recurso no se concede.
La tcnica ms utilizada para realizar este mtodo es el conocido como algoritmo
del banquero sugerido por Dijkstra. Se conoce as porque simula el comportamiento
de un banquero que realiza prstamos y recibe pagos sin caer nunca en la
posibilidad de no poder satisfacer todas las necesidades de sus clientes.
El algoritmo asegura que el nmero de recursos asignados a todos los procesos
nunca puede exceder del nmero de recursos del sistema. Adems, nunca se puede
hacer una asignacin peligrosa, esto es, asignar recursos de modo que no queden
suficientes para satisfacer las necesidades de todos los procesos.

7.3. Deteccin de los interbloqueos

Este tipo de mtodos se utiliza en aquellos sistemas en los que se permite que se
produzca el interbloqueo o, lo que es equivalente, en los que no se comprueba si se
cumplen las condiciones que pueden llevarlo a esta situacin. El modo en que se
procede en este caso es comprobando peridicamente si se ha producido el
interbloqueo. Si es as, se identifican los procesos y los recursos puestos en juegos
para poder dar una solucin. Por este motivo es necesario conservar actualizada la
informacin sobre las peticiones y asignaciones de los recursos a los procesos.
En los mtodos de deteccin y recuperacin hay que tener presente la sobrecarga
que conlleva para el sistema operativo el mantener la informacin necesaria y el
algoritmo de deteccin, as como las posibles prdidas que pueden ocurrir en el
intento de recuperar al sistema.
Grafos de asignacin de recursos.
Para facilitar la deteccin de los interbloqueos se suele utilizar un grafo dirigido que
indica las asignaciones de los recursos a los procesos y las peticiones que estos
realizan. Los nodos del grafo son procesos y recursos y cada arco conecta el nodo
de un proceso con el nodo de un recurso. A este grafo se le denomina grafo de
asignacin de los recursos del sistema.
Andrs S. Egea

Pgina 19 de 22

7.4.-Recuperacin de interbloqueos
Una vez que se ha detectado el interbloqueo se debe romper para que los procesos
puedan finalizar su ejecucin y liberar as los recursos. Para la ruptura de la espera
circular se pueden realizar varias opciones. La idnea seria suspendiendo algunos
de los procesos bloqueados para tomar sus recursos y reanudar su ejecucin una
vez que se hubiera deshecho el interbloqueo. Esta solucin slo puede resultar
factible en casos muy particulares; no se podra suspender a un proceso de escribir
en una impresora para pasarla a otro proceso y reanudar despus la impresin,
como tampoco se podra suspender indefinidamente un proceso de tiempo real. Las
dos opciones que se suelen utilizar son:
reiniciar uno o ms de los procesos bloqueados y expropiar los recursos de algunos
de los procesos bloqueados.
Para aplicar la primera de las opciones se deben tener en cuenta una serie de
factores con el fin de elegir aquellos procesos cuya reiniciacin resulte menos
traumtica. Entre los factores a tener en cuenta en cada proceso se tienen:
1)

La prioridad del proceso

2)

El tiempo de procesamiento utilizado y el que le resta

3)

El tipo y nmero de recursos que posee

4)

El nmero de recursos que necesita para finalizar

5)

El nmero de otros procesos que se veran involucrados con su reiniciacin.

El procedimiento en la segunda opcin consiste en ir expropiando recursos de

algunos procesos de forma sucesiva hasta que se consiga salir del interbloqueo. La
eleccin de los procesos que se expropian se basa en criterios similares a los
expuestos en la reiniciacin de los procesos. Hay otro aspecto a tener en cuenta en
esta opcin, que es el estado al que se pasan los procesos expropiados, ya que al
perder algunos de sus recursos no pueden continuar con su ejecucin normal. La
solucin sera volverlos a un estado anterior en el que el bloqueo se rompa. Para
que esto sea posible se necesita que el sistema disponga de una utilidad que
registre los estados de los distintos procesos en tiempo de ejecucin, con la
consiguiente carga adicional sobre el sistema operativo.
En algunos sistemas de tiempo real el interbloqueo puede tener resultados
inaceptables, por lo que no se puede permitir que se presente dicha situacin. En
otros sistemas se rechaza el interbloqueo, aunque la situacin pudiera ser aceptable,
por el costo en tiempo y medios adicionales que conlleva la recuperacin.
Todos los mtodos que se han visto para tratar el tema del interbloqueo tienen
ventajas e inconvenientes. Se puede obtener una mayor eficacia combinando los
distintos mtodos para aprovechar sus ventajas. Una solucin en este sentido es la
que sigue:
a)Agrupar los recursos del sistema en clases disjuntas.
Andrs S. Egea

Pgina 20 de 22

b)Para evitar el interbloqueo entre las clases se ordenan en la forma que se ha

sealado para evitar la espera circular.
c)Usar en cada clase el mtodo ms apropiado de evitar en ella el interbloqueo.
Como ejemplo de aplicacin de esta solucin, considrese las cuatro clases de
recursos siguientes, ordenadas en la forma en que aparecen.
1)Espacio de intercambio, un rea de bloques de memoria secundaria para
intercambio de procesos con la memoria principal.
2)Recursos de los procesos, tales como impresoras, ficheros, discos y cintas.
3)Memoria principal asignable a los procesos en pginas o segmentos.
4)Recursos internos, tales como canales de EIS.
Las estrategias ms apropiadas para cada clase son las siguientes:
- Espacio de intercambio. Como lo usual es que se conozca de antemano la
capacidad mxima de almacenamiento necesitada por cada proceso, lo ms
adecuado es la prevencin del interbloqueo por el mtodo usado para evitar la
condicin de retencin y espera, esto es, haciendo que se solicite a la vez toda la
memoria necesaria. Tambin se puede utilizar el mtodo de evitacin del
interbloqueo.
- Recursos de los procesos. Normalmente los procesos declaran, antes de pasar a
ejecucin, los recursos de una determinada clase que van a necesitar, por lo que el
mtodo de evitacin de interbloqueos parece el ms adecuado. Tambin cabe la
posibilidad de utilizar el mtodo de la ordenacin de los recursos.
- Memoria principal. El mtodo ms apropiado es la prevencin mediante
expropiacin, ya que cuando un proceso resulta expropiado se pasa a memoria
secundaria.
- Recursos internos. La mejor alternativa puede ser la prevencin por ordenacin de
los recursos, ya que con estos recursos no suele ser necesario realizar ninguna
eleccin en tiempo de ejecucin entre las peticiones pendientes.

8.- Bibliografa.
Alonso Domnguez , V.M. ;
Villarino Fernndez, J.A. : Sistemas operativos : Alhambra Longman . 1994

Morera Pascual, Juan;

Perez Campanero , Juan A.;
Alcande, Eduardo:Introduccin a los Sistemas Operativos. McGraw-Hill. 1992
Andrs S. Egea

Pgina 21 de 22

Aranda Joaqun;
De la cruz, Jesus M;
Canto M Antonia;
Dormido Sebastin: Sistemas Operativos: Sanz y Torres.1996
Prieto , Alberto;
Lloris , Antonio;
Torres , Juan Carlos : Introduccin a la Informtica.McGraw-Hill.1989
Cerrato , Purificacin;
Lzaro Eugenio;
Jarillo M Dolores;
Jarillo Pedro: Sistemas Informticos Multiusuario y en Red: McGraw-Hill.1996

Andrs S. Egea

Pgina 22 de 22