Unidad2

Sistemas Operativos Unidad 2

2. ADMINISTRACIÓN DE PROCESOS
2.1 CONCEPTOS ACERCA DE LOS PROCESOS

El término “proceso” fue utilizado por primera vez por los diseñadores del sistema Multics en los años
sesenta. Desde entonces, el término proceso, utilizado a veces como sinónimo de tarea (task) o trabajo
(job), ha tenido muchas definiciones. A continuación se presentan algunas:
ü Un programa en ejecución
ü Una actividad asíncrona
ü El “espíritu animado” de un procedimiento
ü El “centro de control” de un procedimiento en ejecución
ü Lo que se manifiesta por la existencia de un “bloque de control de proceso” en el sistema
operativo
ü La entidad a la que se asignan los procesadores
ü La unidad “despachable”.

El concepto de “programa en ejecución” parece ser que se utiliza con más frecuencia. Un programa es
una entidad inanimada; sólo cuando un procesador le “infunde vida” se convierte en la entidad “activa”
que se denomina proceso.

Hasta ahora hemos utilizado siempre el término programa. A partir de ahora distinguiremos entre
programa y proceso. Un programa es una secuencia de instrucciones escrita en un lenguaje dado. Un
proceso es una instancia de ejecución de un programa, caracterizado por su contador de programa, su
palabra de estado, sus registros del procesador, su segmento de texto, pila y datos, etc. Un programa es
un concepto estático, mientras que un proceso es un concepto dinámico. Es posible que un programa
sea ejecutado por varios usuarios en un sistema multiusuario, por cada una de estas ejecuciones existirá
un proceso, con su contador de programa, registros, etc. El sistema operativo necesita el concepto de
proceso para poder gestionar el procesador mediante la técnica de multiprogramación o de tiempo
compartido, de hecho, el proceso es la unidad planificable, o de asignación de la CPU.

2.2 ESTADOS DE UN PROCESO

Un proceso pasa por una serie de estados discretos, algunos de ellos son:
ü En ejecución: El proceso ocupa la CPU actualmente, es decir, se está ejecutando.
ü Listo o preparado: El proceso dispone de todos los recursos para su ejecución, sólo le falta la
CPU.
ü Bloqueado: Al proceso le falta algún recurso para poder seguir ejecutándose, además de la
CPU. Por recurso se pueden entender un dispositivo, un dato, etc. El proceso necesita que
ocurra algún evento que le permita poder proseguir su ejecución.

Varios eve ntos pueden ocasionar que un proceso cambie de estado. Se dice que un proceso se está
ejecutando, es decir, se encuentra en estado de ejecución, si tiene asignada la unidad central de
procesamiento (CPU de aquí en adelante).

Se dice que un proceso está listo (es decir, se encuentra en estado listo) si pudiera utilizar una CPU en
caso de haber una disponible. Un proceso está bloqueado (es decir, se encuentra en estado bloqueado)
si está esperando que suceda algún evento (como un evento de fin de E/S, por ejemplo) antes de poder
proseguir su ejecución.

Universidad Autónoma de Nayarit 1


Hay otros estados de los procesos, pero en el presente curso se tratarán estos tres. Por sencillez, se
considera un sistema con una sola CPU, aunque no es difícil la extensión a múltiples procesadores.
Solamente puede haber un proceso en ejecución a la vez, pero puede haber varios listos y varios pueden
estar bloqueados. Así pues, se forma una lista de procesos listos y otras de procesos bloqueados. La
lista de procesos listos se ordena por prioridad, de manera que el siguiente proceso que reciba la CPU
será el primero de la lista. La lista de procesos bloqueados normalmente no está ordenada; los procesos
no se desbloquean (es decir, no pasan a ser procesos listos) en orden de prioridad, sino que lo hacen en
el orden de ocurrencia de los eventos que están esperando.

Como se verá más adelante, hay situaciones en las cuales varios procesos pueden bloquearse esperando
la ocurrencia del mismo evento; en tales casos es común asignar prioridades a los procesos que
esperan.

2.3 TRANSICIONES DE ESTADO DE LOS PROCESOS

Cuando se admite una tarea en el sistema, se crea el proceso correspondiente y se inserta normalmente
al final de la lista de procesos listos. El proceso se desplaza poco a poco hacia el frente de la lista de
procesos listos, a medida que los procesos que se encuentran antes que él completan su turno de uso de
la CPU. Cuando el proceso llega al principio de la lista, se le asigna la CPU cuando ésta queda
disponible y entonces se dice que hay una transición de estado del estado listo al estado de ejecución.

La asignación del procesador al primer proceso de la lista de procesos listos se denomina despacho;
dicha actividad la realiza una entidad del sistema llamada despachador. Esa transición se indica como
sigue:

Para evitar que un proceso monopolice el sistema, en forma accidental o mal intencionada, el sistema
operativo utiliza un reloj de interrupción por hardware (o cronómetro de intervalos) para que las tareas
de este usuario se ejecuten durante un intervalo específico de tiempo o quantum.

Si el proceso no libera voluntariamente la CPU antes de que expire el intervalo de tiempo, el reloj
genera una interrupción, haciendo que retome el control el sistema operativo.



El sistema operativo transforma entonces el proceso que estaba ejecutándose en un proceso listo y
procede a ejecutar el primero de los procesos de la cola de listos. Estas transiciones de estado se
indican así:
tiempo_expirado (nombre_del_proceso):en_eje cución? listo
y
despachar (nombre_del proceso): listo ? en ejecución

Los relojes sirven para mantener la hora del día, indicar la expiració n de los quantums, contabilizar el
uso de los recursos, dar notificaciones a los procesos en los momentos designados y acumular
estadísticas de desempeño. Algunas computadoras utilizan baterías para mantener funcionando los
relojes aun cuando esté apagado el sistema.

Si el proceso que se está ejecutando inicia una operación de E/S antes de que expire su quantum, libera
voluntariamente la CPU (es decir, el proceso se bloquea a sí mismo esperando a que se complete la
operación de E/S). Esta transición de estado es
bloquear(nombre_del_proceso): en ejecución? bloqueado

La última transición posible en este modelo de tres estados ocurre cuando se completa una operación de
E/S (o algún otro evento que espere un proceso). El proceso realiza la transición del estado bloqueado
al estado listo. La transición es
despertar (nombre_del_proceso):bloqueado? listo

De esta forma se han definido cuatro posibles transiciones de estado:
despachar (nombre_del_proceso):listo? en_ejecución
tiempo_expirado (nombre_del_proceso):en_ejecución? listo
bloquear (nombre_del_proceso):en_ejecución? bloqueado
despertar (nombre_del_proceso):bloqueado? listo

Obsérvese que la única transición de estado iniciada por el proceso de usuario es el bloqueo; las otras
tres transiciones son iniciadas por entidades externas al proceso.

2.4 EL BLOQUE DE CONTROL DE PROCESO
La forma en que se manifieste un proceso en un sistema operativo es mediante un bloque de control de
proceso (process control block o PCB) o un descriptor de proceso. El PCB es una estructura de datos
que contiene información importante acerca de un proceso, esto es, un almacén central de información
que permite al sistema operativo localizar toda la información importante acerca de un proceso.

Cuando el sistema operativo conmuta la CPU entre varios procesos activos, utiliza las áreas de
salvaguarda de los PCB para guardar la información que necesita para reiniciar un proceso cuando éste
obtenga la CPU nuevamente.

Así pues, el PCB es la entidad que define un proceso al sistema operativo. Dado que los PCB necesitan
ser manejados con eficiencia por el sistema operativo, muchos sistemas de cómputo tienen un registro
de hardware que siempre apunta hacia el PCB del proceso que se está ejecutando. A menudo existen
instrucciones de hardware que cargan en el PCB información acerca del estado, y que la recuperan con
rapidez.



Elementos Básicos de un bloque de Control de Proceso
Identificación del Proceso

Los identificadores numéricos que se pueden guardar en el bloque de control de proceso incluyen:
ü Identificador de este proceso
ü Identificador del proceso que creó a este proceso (el proceso padre)
ü Identificador del usuario

Información de Estado del Procesador

Registros Visibles para el Usuario
Un registro visible para el usuario es aquél al que puede hacerse referencia por medio del lenguaje
máquina que ejecuta el procesador. Normalmente, existen de 8 a 32 de estos registros, aunque algunas
implementaciones RISC tiene n más de 100.

Registros de Control y de Estado
Hay varios registros del procesador que se emplean para controlar su funcionamiento, Entre estos se
incluyen:
ü Contador de programa: Contiene la dirección de la próxima instrucción a ser tratada.
ü Códigos de condición: Muestran el resultado de la operación aritmética o lógica más reciente
(signo, cero, acarreo, igualdad, desbordamiento).
ü Información de estado: Incluye los indicadores de habilitación o inhabilitación de
interrupciones y el modo de ejecución.

Apuntadores de stack
Cada proceso tiene uno o más stacks del sistema asociados. Los stacks se utilizan para almacenar los
parámetros y las direcciones de retorno de los procedimientos y de las llamadas al sistema. El
Apuntador al stack siempre apunta al elemento indicado por el tope.

Información de Control del Proceso

Información de Planificación y de Estado
Esta es la información que se necesita por el sistema operativo para llevar a cabo sus funciones de
planificación. Los elementos típicos de esta información son los siguientes:
ü Estado del proceso: Define la disposición del proceso para ser planificado para ejecutar (en
ejecución, listo, esperando, detenido).
ü Prioridad: Se puede usar uno o más campos para describir la prioridad de planificación de los
procesos. En algunos sistemas se necesitan varios valores (por omisión, actual, la más alta
permitida).
ü Información de planificación: Ésta dependerá del algoritmo de planificación utilizado. Como
ejemplos se tienen la cantidad de tiempo que el proceso ha estado esperando y la cantidad de
tiempo que el proceso ejecutó la última vez.
ü Suceso: La identidad del suceso que el proceso está esperando antes de poder reanudarse.

Estructuración de Datos
Un proceso puede estar enlazado con otros procesos en una cola, un anillo o alguna otra estructura. Por
ejemplo todos los procesos que están en estado de espera de un nivel determinado de prioridad pueden
estar enlazados en una cola.


Un proceso puede mostrar una relación padre- hijo (creador-creado) con otro proceso. El bloque de
control de proceso puede contener apuntadores a otros procesos para dar soporte a estas estructuras.

Comunicación entre Procesos
Puede haber varios indicadores, señales y mensajes asociados con la comunicación entre dos procesos
independientes. Una parte de esta información o toda ella se puede guardar en el bloque de control de
proceso.

Información de Control del Proceso

Privilegios de los procesos
A los procesos se les otorgan privilegios en términos de la memoria a la que pueden acceder y el tipo
de instrucciones que pueden ejecutar. Además, también se pueden aplicar privilegios al uso de los
servicios y utilidades del sistema.

Gestión de Memoria
Esta sección puede incluir apuntadores a las tablas de páginas y/o segmentos que describen la memoria
virtual asignada al proceso.

Propiedad de los Recursos y Utilización
Se pueden indicar los recursos controlados por el proceso, tales como los archivos abiertos. También se
puede incluir un histórico de la utilización del procesador o de otros recursos; esta información puede
ser necesaria para el planificador.

2.5 PROCESAMIENTO DE INTERRUPCIONES
En un sistema de cómputo, una interrupció n es un evento que altera la secuencia en que el procesador
ejecuta las instrucciones.

La interrupción es generada por el hardware del sistema de cómputo. Cuando ocurre una interrupción:
ü El sistema operativo toma el control (es decir, el hardware pasa el control al sistema operativo).
ü El sistema operativo guarda el estado actual del proceso interrumpido en el PCB del proceso
(conmutación de contexto).
ü El sistema operativo aplica la transición: bloquear (nombre_del_proceso): en_ejecución ?
bloqueado
ü El manejador de interrupciones del sistema operativo analiza la interrupción y transfiere el
control a la rutina apropiada para atenderla; en muchos sistemas el hardware se encarga de esto
automáticamente.
ü La rutina seleccionada por el manejador de interrupciones procesa la interrupción.
ü El sistema operativo aplica la transición: despachar (nombre_del_proceso): listo ? en_ejecución
ü Cuando se ha terminado de atender el evento que generó la interrupción el sistema operativo
aplica la transición: despertar (nombre_del_proceso): bloqueado ? listo

Una interrupción puede ser iniciada específicamente por un proceso en ejecución (en cuyo caso se
suele denominar trampa (trap), y se dice que está sincronizada con la operación del proceso) o puede
ser causada por algún evento que puede estar relacionado o no con el proceso en ejecución (en cuyo
caso se dice que es asíncrona con la operación del proceso).



Una ventaja importante de las interrupciones es que son una forma económica de llamar la atención de
la CPU, de este modo no necesita escrutar constantemente los dispositivos para ver si alguno requiere
atención. Un ejemplo simple de la diferencia de escrutinio e interrupción se puede observar en las
cocinas modernas equipadas con hornos de microondas. El cocinero puede ajustar un reloj para que se
detenga después de cierto tiempo (un ejemplo de interrupción es el sonido que produce la alarma
cuando transcurre el tiempo), o bien, el cocinero puede mirar periódicamente a través de la ventana del
horno para ver cómo se cocina el asado (esta clase de vigilancia periódica es un ejemplo de escrutinio).

Los sistemas orientados hacia las interrupciones pueden sobrecargarse. Si estas llegan con mucha
frecuencia, el sistema no será capaz de atenderlas. Un controlador de humano de tráfico aéreo podría
verse fácilmente abrumado si convergieran muchos aviones en una zona reducida. En algunos sistemas
orientados hacia el teclado, cada tecla presionada almacena en la memoria un código de un byte y
genera una interrupción para informar a la CPU que un carácter esta listo para ser procesado. Si la CPU
no puede procesar el dato antes de que se presione la siguiente tecla, se pierde el primer carácter.

Clases de interrupciones

En términos generales puede considerarse que existen seis clases de interrupciones:
ü Interrupciones SVC (supervisor call, llamadas al supervisor). Son iniciadas por un proceso en
ejecución que ejecute la instrucción SVC. Una SVC es una petición generada por el usuario de
un servicio particular del sistema, como realizar una operación de E/S, obtener más memoria o
comunicarse con el operador del sistema. El mecanismo de las SVC ayuda a proteger el sistema
operativo de las acciones de los usuarios. Un usuario no puede entrar arbitrariamente al sistema
operativo, sino que debe solicitar un servicio por medio de una SVC. El sistema operativo está
al tanto de todos los usuarios que intentan rebasar sus límites y puede rechazar ciertas
peticiones si el usuario no tiene los privilegios necesarios.
ü Interrupciones de E/S. Son iniciadas por hardware de entrada y salida. Estas interrupciones
indican a la CPU el cambio de estado de un canal o un dispositivo. Las interrupciones de E/S se
producen cuando finaliza una operación de E/S o cuando un dispositivo pasa al estado listo, por
ejemplo.
ü Interrupciones externas. Son causadas por diversos eventos, incluyendo la expiración de un
cuanto de un reloj que interrumpe, la pulsación de la tecla de interrupción de la consola o la
recepción de una señal procedent e de otro procesador en un sistema de múltiples procesadores.
ü Interrupciones de reinicio. Ocurre cuando se presiona el botón de reinicio de la consola o
cuando llega desde otro procesador una instrucción de reinicio (señal del procesador) en un
sistema de múltiples procesadores.
ü Interrupciones de verificación del programa. Son causadas por una amplia clase de
problemas que pueden ocurrir cuando se ejecutan las instrucciones en lenguaje de máquina de
un programa. Dichos problemas incluyen la división entre cero, el exceso o defecto de los
números que pueden ser manejados por las operaciones aritméticas, la presencia de datos (con
los cuales se está trabajando) con un formato erróneo, el intento de ejecutar un código de
operación inválido, el intento de hacer referencia a una localidad de memoria que esté fuera de
los limites de la memoria real, el intento por parte de un proceso de usuario de ejecutar una
instrucción privilegiada y el intento de hacer referencia a un recurso protegido. Muchos
sistemas ofrecen a los usuarios la opción de especificar las rutinas que deben ejecutarse cuando
ocurra una interrupción de verificación del programa.
ü Interrupciones de verificación de la máquina. Son ocasionadas por el mal funcionamiento
del hardware.



2.6 SECCIONES CRÍTICAS
El fenómeno de exclusión mutua genera entre otras cosas, la necesidad de programar secciones o
regiones críticas que permitan el acceso a recursos compartibles por múltiples procesos, de manera que
la integridad de los datos de preserve.

La exclusión mutua debe ponerse en práctica cuando los procesos obtienen acceso a datos compartidos
modificables; cuando los procesos realizan operaciones que no entran en conflicto con otras, debe
permitirse que procedan concurrentemente. Cuando un proceso obtiene acceso a datos compartidos
modificables, se dice que se encuentra en una sección crítica o región critica.

Mientras un proceso se encuentra en su sección crítica, otros procesos pueden, claro está, seguir
ejecutándose fuera de sus secciones críticas. Cuando un proceso abandona su región crítica, otro
proceso que esperaba entrar en su propia sección crítica podrá hacerlo (si existe algún proceso en
espera). Lograr que se cumpla la exclusión mutua es uno de los problemas fundamentales de la
programación concurrente. Se han propuesto muchas soluciones, algunas de software y otras de
hardware, algunas sencillas y otras complejas, y algunas que requieren la cooperación voluntaria de los
procesos y otras que exigen un estricto ajuste a rígidos protocolos.

Encontrarse dentro de una región crítica es un estado especial concedido a un proceso. El proceso tiene
acceso exclusivo a los datos compartido y los demás procesos que requieran acceso a los datos en ese
momento deben esperar. Así pues, las secciones críticas deben ejecutarse tan rápido como sea posible;
un proceso no debe bloquear dentro de su propia sección crítica y las secciones críticas deben
codificarse con mucho cuidado (para evitar, por ejemplo, la posibilidad de ciclos infinitos).

Si un proceso de una sección crítica termina, ya sea voluntaria o involuntariamente, el sistema
operativo, al realizar su mantenimiento de terminaciones, debe liberar la exclusión mutua de manera
que otros procesos puedan entrar en sus regiones críticas.

2.7 SEMÁFOROS Y MONITORES

SEMÁFORO
La contribución más importante de la comunicación entre procesos fué la introducción del concepto de
semáforos (Dijkstra, 1965) y el funcionamiento de las primitivas wait y signal que actúan sobre ellos.
Un semáforo es una variable entera no negativa que, aparte de su valor inicial, sólo puede ser activada
por las operaciones wait y signal. Estas operaciones sólo actúan en los semáforos, y su efecto se define
como sigue.

signal(s)
Su efecto es aumentar el valor del semáforo s en uno, el incremento será considerado como una
operación indivisible. La indivisibilidad implica que signal(s) no es equivalente a la sentencia de
asignación s = s + 1. Suponga que dos procesos A y B desean realizar una operación signal(s) cuando
el valor de s es, digamos 3. Entonces el valor de s cuando ambas operaciones estén completos será 5.
Suponga por otro lado que en circunstancias similares ambos procesos desearon ejecutar s = s + 1. Esta
declaración sería implementada como tres operaciones en más de un hardware; lee s, agregue uno, y
almacene s; esto sería verdad aun cuando una sola instrucción de máquina siempre fuera usada para
incrementar s. No habría ninguna garantía que A complete las tres operaciones antes de que B
empezara; si no fuera así cada proceso podría asignar el valor 4 entonces a s, y se perdería uno de los
incrementos deseados.



wait(s)
El efecto es disminuir el valor del semáforo s en 1, en cuanto el resultado fuera no negativo. De nuevo
la operación es indivisible. La operación wait implica un retraso potencial, para cuando actúe en un
semáforo cuyo valor es 0, el proceso que ejecuta la operación sólo puede proceder cuando algún otro
proceso ha aumentado el valor del semáforo a 1 por una operación signal. La indivisibilidad de la
operación indica que si algunos procesos son borrados entonces solo uno de ellos puede completar
exitosamente la operación cuando el semáforo se pone positivo. No se hace suposición alguna sobre
que proceso es éste. Los efectos de las operaciones de wait y signal pueden resumirse como:
ü wait(s): si s > 0 decrementa s
ü signal (s): incrementa s
donde s es cualquier semáforo.

MONITORES
Un programador puede poner fácilmente wait y signal en lugares no convenientes, o incluso omitirlos
en su totalidad. Por ejemplo, un programador que no comprende que una estructura de datos particular
será compartida por varios procesos omitirá en las operaciones wait y signal la sección crítica del
programa que accedan. La estructura de datos estará entonces indefensa de la manipulación simultánea
por varios procesos, y las inconsistencias en sus contenidos probablemente sucederán.

Para evitar tales problemas ha habido varios propuestas que obligan al programador a que declare datos
compartido y recursos explícitos, y que de fuerza a la exclusión mutua de acceso a objetos compartidos.
Uno de los más influyentes y ampliamente adoptado es el monitor (Hoare, 1974)

Un monitor consiste de:
1. Los datos que comprenden un objeto compartido
2. Un juego de procedimientos que pueden llamarse para acceder el objeto
3. Una porción de programa que inicializa el objeto (este programa sólo se ejecuta una vez, cuando el
objeto se crea)

Por ejemplo, un buffer para los campos de datos de paso entre los procesos del productor y procesos
del consumidor podría representarse por un monitor que consiste de:
1. El espacio del buffer e indicadores (por ejemplo, un arreglo, e índices dentro de este)
2. Dos procedimientos depositar y extraer que pueden ser llamados por los procesos para poner un
campo en el buffer o remover un campo de este.
3. Una pieza de programa que inicializa el apuntador del buffer al comienzo.

El compilador de un lenguaje que incorpora a los monitores debe asegurar que acceda un objeto
compartido que sólo puede hacerse llamando un procedimiento del monitor correspondiente. El
compilador también debe asegurar que los procedimientos de cada monitor sean implementados como
exclusión mutua, secciones críticas. El compilador puede hacer bien esto con las operaciones wait y
signal de los semáforos apropiados en el programa compilado. Así, en el ejemplo del buffer, el
compilador garantiza que el acceso al buffer es restringido al depositar y extraer procedimientos, y que
esos procedimientos son mutuamente excluyentes.

Debe estar claro que los monitores eliminan una fuente potencialmente fértil de errores transfiriendo la
responsabilidad por la exclusión mutua del programador al compilador. La responsabilidad para otras
formas de restos de sincronización, sin embargo, con el programador debe usar los semáforos (o algo
equivalente) para efectuarlo.



Por ejemplo, la representación de un buffer como un monitor asegura a través de la exclusión mutua de
depositar y extraer ese campo que no puede ser simultáneamente insertados o borrados. Esto no se
hace, sin embargo, previniendo procesos que depositan campos en un buffer lleno o vaciando uno.
Tales desastres deben ser prevenidos poniendo las operaciones de sincronización apropiados dentro de
las operaciones depositar y extraer.

La estructura del monitor se ha llevado a cabo en varios lenguajes de programación, como Concurrent
Pascal (Hansen, 1975), Pascal-plus (Welsh y Bustard, 1979), Mesa (Lampson -y Redell, 1980), y
Turing (Holt y Cordy, 1988). Para el administrador del sistema operativo tiene la ventaja de restringir
todas las operaciones en un objeto compartido a un juego de procedimientos bien definidos, y de
asegurar que estas operaciones son mutuamente exclusivas.

2.8 INTERBLOQUEO (DEADLOCK)

Bloqueo Mutuo O Abrazo Mortal
Los bloqueos mutuos pueden aparecer de muchas formas. Si a un proceso se le asigna la tarea de
esperar a que ocurra un evento y el sistema no incluye providencias para señalar la ocurrencia de dicho
evento, habrá un bloqueo mutuo con un solo proceso. La ma yor parte de los bloqueos mutuos en los
sistemas reales implican una competencia entre varios procesos por varios recursos.

Un problema afín: Aplazamiento indefinido

En cualquier sistema que mantenga los procesos en espera mientras se les asigna un recurso o se toman
decisiones de planificación, la programación de un proceso puede postergarse indefinidamente mientras
otro recibe la atención del sistema. Tal situación se conoce con varios nombres, entre los que se
incluyen aplazamiento indefinido, bloqueo indefinido e inanición, y puede resultar tan peligrosa como
un bloqueo mutuo.

El aplazamiento indefinido puede ocurrir debido a predisposiciones en las políticas de planificación de
recursos del sistema. Cuando los recursos se planifican por prioridad, es posible que un proceso dado
espere en forma indefinida un recurso por que siguen llegando otros procesos con mayor prioridad. La
espera es un hecho de la vida real y es sin duda un aspecto muy importante de lo que ocurre dentro de
los sistemas de cómputo. Los sistemas deben diseñarse para administrar los procesos en espera de
manera justa además de eficiente. En algunos sistemas, el aplazamiento indefinido se evita aumentando
la prioridad del proceso mientras espera. Esto se conoce como envejecimiento. En algún momento la
prioridad de ese proceso superará la prioridad de los otros procesos entrantes y el proceso en espera
será atendido.

2.8.1 PRINCIPIOS DEL INTERBLOQUEO

Todos los interbloqueos suponen demandas contradictorias de recursos por parte de dos o más
procesos. La figura de avance conjunto de los procesos P1 y P2 ilustra este conflicto de forma
abstracta en el caso de dos procesos y dos recursos. Los dos ejes del diagrama representan el avance de
los dos procesos en términos de instrucciones ejecutadas. El avance conjunto de los dos procesos se
representa entonces con una secuencia discreta de puntos en el espacio. Las líneas horizontales o
verticales representan el intervalo de tiempo en el que sólo uno de los procesos está ejecutándose
(intercalado); una línea diagonal significa ejecución simultánea (solapamiento).



Supóngase que existe un punto en la ejecución de cada proceso en el que se requiere el uso exclusivo
de ambos recursos, R1 y R2, para continuar. En el ejemplo, llega un punto en el que el proceso P1 ha
adquirido el recurso R1 y el proceso P2 ha adquirido el recurso R2 y cada proceso necesita el otro
recurso. Este es el punto de interbloqueo.

Recursos Reutilizables

Se pueden distinguir dos categorías generales de recursos: reutilizables y consumibles. Un recurso
reutilizables es aquél que pude ser utilizado con seguridad por un proceso y que no se agota con el uso.
Los procesos tienen unidades de recursos que liberan posteriormente para que otros procesos las
utilicen.

Como ejemplos de recursos reutilizables se tiene los procesadores, canales de E/S, memoria principal y
secundaria, dispositivos y estructura de datos tales como archivos, bases de datos y semáforos.

Como ejemplo de interbloqueo con recursos reutilizables, considérense dos procesos que compiten por
el acceso exclusivo a un archivo D del disco y a una unidad de cinta T.

Los programas están dedicados a las siguientes operaciones repetidas:
P1 P2 repeat repeat
... ...
Solicitar (D); Solicitar (T); ... ... Solicitar (T); Solicitar (D); ... ... Liberar (T); Liberar (D); ... ... liberar (D); liberar (T);
... ...
forever forever



El interbloqueo se produce si cada proceso retiene un recurso y solicita el otro. Puede parecer que es un
error de programación en lugar de un error del diseño del sistema operativo. Sin embargo, se ha visto
que el diseño de un programa concurrente entraña gran dificultad. Se producen interbloqueos como éste
y la causa está frecuentemente en la compleja lógica del programa, lo que hace más difícil su detección.
Una posible estrategia para resolver estos interbloqueos es imponer restricciones en el diseño del
sistema sobre el orden en el que se solicitan los recursos.

Otro ejemplo de interbloqueo con un recurso reutilizable tiene que ver con las peticiones a memoria
principal. Supóngase que el espacio disponible es de 200KB y se origina la siguiente secuencia de
peticiones:
P1 P2
... ...
Solicitar 80K bytes; Solicitar 70K bytes;
... ...
Solicitar 60K bytes; Solicitar 80K bytes;

Se produce un interbloqueo si ambos procesos avanzan hasta su segunda petición. Si la cantidad de
memoria que van a solicitar no se conoce con antelación, resulta difícil enfrentarse a este tipo de
interbloqueo por medio de restricciones en el diseño del sistema. La mejor forma de resolver este
problema en particular es, de hecho, eliminar la posibilidad, por medio de la memoria virtual.

Recursos Consumibles

Un recurso consumible es aquél que puede ser creado (producido) y destruido (consumido).
Normalmente, no hay límite en el número de recursos consumibles de un tipo en particular. Un proceso
productor que no está bloqueado puede liberar cualquier número de recursos consumibles. Cuando un
proceso adquiere un recurso, éste deja de existir. Como ejemplos de recursos consumibles están las
interrupciones, señales, mensajes, e información en buffers de E/S.

Como ejemplo de interbloqueo con recursos consumibles, considérese el siguiente par de procesos:
P1 P2
... ...
Recibir (P2, M); Recibir (P1, Q);
... ...
Enviar (P2,N); Enviar (P1, R);

El interbloqueo se produce si el receptor se bloquea. De nuevo, la causa del interbloqueo es un error de
diseño. Estos errores pueden ser bastante sutiles y difíciles de detectar. Es más, puede darse una
combinación de sucesos poco habitual que origine el interbloqueo; así pues, un programa puede
funcionar durante un periodo de tiempo considerable, incluso años, antes de que el problema se
manifieste.
No hay ninguna estrategia sencilla que puede solucionar todas las clases de interbloqueo. A
continuación se resumen los elementos claves de los enfoques más importantes que se han tomado:
detección, prevención y predicción.



Condiciones de Interbloqueo
Deben darse tres condiciones para que pueda producirse un interbloqueo:
1. Exclusión mutua: Sólo un proceso puede usar un recurso simultáneamente.
2. Retención y espera: Un proceso puede retener los recursos asignados mientras espera que se le
asignen otros.
3. No apropiación: Ningún proceso puede ser forzado a abandonar un recurso que retenga.

En la mayoría de los casos, estas condiciones son bastante necesarias. Por ejemplo, la exclusión mutua
hace falta para asegurar la consistencia de resultados y la integridad de la base de datos. De forma
similar, la expulsión o apropiación no se puede aplicar arbitrariamente y, cuando se encuentran
involucrados recursos de datos especialmente, debe estar acompañada de un mecanismo de
recuperación y reanudación, que devuelva a un proceso y a sus recursos a un estado previo adecuado,
desde el que el proceso pueda finalmente repetir sus acciones.

Puede existir interbloqueo con estas tres condiciones, pero puede no existir con sólo estas tres
condiciones. Para que se produzca interbloqueo, se necesita una cuarta condición:

4. Círculo vicioso de espera: Existe una cadena cerrada de procesos, cada uno de los cuales retiene, al
menos, un recurso que necesita el siguiente proceso de la cadena.

Las tres primeras condiciones son necesarias, pero no suficientes, para que exista interbloqueo. La
cuarta condición es, en realidad, una consecuencia potencial de las tres primeras. Es decir, dado que se
producen las tres primeras condiciones, puede ocurrir una secuencia de eventos que desemboque en un
círculo vicioso de espera irresoluble. Un círculo de espera irresoluble es, de hecho, la definición de
interbloqueo. El círculo de espera de la condición 4 es irresoluble porque se mantienen las tres primeras
condiciones. Es decir, las cuatro condiciones en conjunto constituyen una condición necesaria y
suficiente para el interbloqueo.



2.8.2 PREVENCIÓN DEL INTERBLOQUEO
La estrategia de prevención del interbloqueo consiste, a grandes rasgos, en diseñar un sistema de
manera que esté excluida, a priori, la posibilidad de interbloqueo. Los métodos para prevenir el
interbloqueo son de dos tipos. Los métodos indirectos consisten en impedir la aparición de alguna de
las tres condiciones necesarias, antes mencionadas (condiciones 1 a 3). Los métodos directos consisten
en evitar la aparición del círculo vicioso de espera (condición 4). Se examinarán a continuación las
técnicas relacionadas con cada una de las cuatro condiciones.
Negación de la condición de Exclusión Mutua
En general, la primera de las cuatro condiciones no puede anularse. Si el acceso a un recurso
necesita exclusión mutua, el sistema operativo debe soportar la exclusión mutua. Algunos recursos,
como los archivos, pueden permitir varios accesos para lectura, pero sólo accesos exclusivos para
escritura. Incluso en este caso, se puede producir interbloqueo si más de un proceso necesita permiso de
escritura.
Negación de la condición de Retención y Espera
La condición de retención y espera puede prevenirse exigiendo que todos los procesos soliciten
todos los recursos que necesiten a un mismo tiempo y bloqueando el proceso hasta que todos los
recursos puedan concederse simultáneamente. Esta solución resulta ineficiente por dos factores. En
primer lugar, un proceso puede estar suspendido durante mucho tiempo, esperando que se concedan
todas sus solicitudes de recursos, cuando de hecho podría haber ava nzado con sólo algunos de los
recursos.
Y en segundo lugar, los recursos asignados a un proceso pueden permanecer sin usarse durante
periodos considerables, tiempo durante el cual se priva del acceso a otros procesos.
Negación de la condición de No apropiación

La condición de no apropiación puede prevenirse de varias formas. Primero, si a un proceso que
retiene ciertos recursos se le deniega una nueva solicitud, dicho proceso deberá liberar sus recursos
anteriores y solicitarlos de nuevo, cuando sea necesario, junto con el recurso adicional. Por otra parte,
si un proceso solicita un recurso que actualmente está retenido por otro proceso, el sistema operativo
puede expulsar al segundo proceso y exigirle que libere sus recursos. Este último esquema evitará el
interbloqueo sólo si no hay dos procesos que posean la misma prioridad.
Esta técnica es práctica sólo cuando se aplica a recursos cuyo estado puede salvarse y restaurarse más
tarde de una forma fácil, como es el caso de un procesador.
Negación de la condición Círculo Vicioso de Espera
La condición del círculo vicioso de espera puede prevenirse definiendo una ordenación lineal de
los tipos de recursos. Si a un proceso se le han asignado recursos de tipo R, entonces sólo podrá realizar
peticiones posteriores sobre los recursos de los tipos siguientes a R en la ordenación.

Para comprobar el funcionamiento de esta estrategia, se asocia un índice a cada tipo de recurso.
En tal caso, el recurso Ri antecede a Rj en la ordenación si i < j. Entonces, supóngase que dos procesos
A y B se interbloquean, porque A ha adquirido R y solicitado Rj, mientras que B ha adquirido Rj y
i
solicitado Ri. Esta situación es imposible porque implica que i <j y j < i.
Como en la retención y espera, la prevención del círculo vicioso de espera puede ser ineficiente,
retardando procesos y denegando accesos a recursos innecesariamente.



2.8.3 DETECCIÓN DEL INTERBLOQUEO
Las estrategias de prevención del interbloqueo son muy conservadoras; solucionan el problema
del interbloqueo limitando el acceso a los recursos e imponiendo restricciones a los procesos. En el
lado opuesto, las estrategias de detección del interbloqueo no limitan el acceso a los recursos ni
restringen las acciones de los procesos. Con detección del interbloqueo, se consideran los recursos que
los procesos necesiten siempre que sea posible. Periódicamente, el sistema operativo ejecuta un
algoritmo que permite detectar la condición de círculo vicioso de espera descrita en el punto 4 anterior
e ilustrada en el Resumen de los enfoques de detección, prevención y predicción del interbloqueo
en los sistemas operativos mencionados anteriormente. Puede emplearse cualquier algoritmo de
detección de ciclos en grafos dirigidos.
El control del interbloqueo puede llevarse a cabo tan frecuentemente como las solicitudes de
recursos o con una frecuencia menor, dependiendo de la probabilidad de que se produzca el
interbloqueo. La comprobación en cada solicitud de recurso tiene dos ventajas: Conduce a una pronta
detección y el algoritmo es relativamente simple, puesto que está basado en cambios increméntales del
estado del sistema. Por otro lado, tal frecuencia de comprobaciones consume un tiempo de procesador
considerable.
Una vez detectado el interbloqueo, hace falta alguna estrategia de recuperación. Las técnicas
siguientes son posibles enfoques, enumeradas en orden creciente de sofisticación:
1. 1. Abandonar todos los procesos bloqueados. Esta es, se crea o no, una de las soluciones más
comunes, si no la más común, de las adoptadas en un sistema operativo.
2. 2. Retroceder cada proceso interbloqueado hasta algún punto de control definidopreviamente y
volver a ejecutar todos los procesos. Es necesario que haya disponibles unos mecanismos de retroceso
y reinicio en el sistema. El riesgo de esta solución radica en que puede repetirse el interbloqueo
original. Sin embargo, el no determinismo del procesamiento concurrente asegura, en general, que esto
no va a pasar.
3. 3. Abandonar sucesivamente los procesos bloqueados hasta que deje de haber interbloqueo. El
orden en el que se seleccionan los procesos a abandonar seguirá un criterio de mínimo coste. Después
de abandonar cada proceso, se debe ejecutar de nuevo el algoritmo de detección para ver si todavía
existe interbloqueo.
4. 4. Apropiarse de recursos sucesivamente hasta que deje de haber interbloqueo. Como en el
punto 3, se debe emplear una selección basada en coste y hay que ejecutar de nuevo el algoritmo de
detección después de cada apropiación. Un proceso que pierde un recurso por apropiación debe
retroceder hasta un momento anterior a la adquisición de ese recurso.

Para los puntos 3 y 4, el criterio de selección podría ser uno de los siguientes, consistentes en escoger el
proceso con:
ü La menor cantidad de tiempo de procesador consumido hasta ahora
ü El menor número de líneas de salida producidas hasta ahora
ü El mayor tiempo restante estimado

ü El menor número total de recursos asignados hasta ahora

ü La prioridad más baja
Algunas de estas cantidades son más fáciles de medir que otras. El tiempo restante estimado deja
lugar a dudas, especialmente. Además, aparte de las medidas de prioridad, no existe otra indicación del
"coste" para el usuario frente al coste para el sistema en conjunto.



2.8.4 PREDICCIÓN DEL INTERBLOQUEO
Otra forma de resolver el problema del interbloqueo, que se diferencia sutilmente de la prevención, es
la predicción de interbloqueo. En la prevención de interbloqueo, se obligaba a las solicitudes de
recursos a impedir que sucediera, por lo menos, alguna de las cuatro condiciones de interbloqueo.

Esto se hace indirectamente, impidiendo la aparición de una de las tres condiciones necesarias
(exclusión mutua, retención y espera, no apropiación) o directamente, impidiendo la aparición de un
círculo vicioso de espera.

Se llega así a un uso ineficiente de los recursos y una ejecución ineficiente de los procesos. Con
predicción del interbloqueo, por otro lado, se pueden alcanzar las tres condiciones necesarias, pero se
realizan elecciones acertadas para asegurar que nunca se llega al punto de interbloqueo. La predicción,
por tanto, permite más concurrencia que la prevención. Con predicción del interbloqueo, se decide
dinámicamente si la petición actual de asignación de un recurso podría, de concederse, llevar
potencialmente a un interbloqueo.

La predicción del interbloqueo necesita, por tanto, conocer las peticiones futuras de recursos.

Dos enfoques para la predicción del interbloqueo:

ü No iniciar un proceso si sus demandas pueden llevar a interbloqueo.

ü No conceder una solicitud de incrementar los recursos de un proceso si esta asignación puede
llevar a interbloqueo.
Una Estrategia Integrada de Interbloqueo

Como se propone en el Resumen de los enfoques de detección, prevención y predicción del
interbloqueo en algunos sistemas operativos, hay puntos fuertes y debilidades en todas las estrategias
de solución del interbloqueo.
En lugar de intentar diseñar un servicio del sistema operativo que emplee sólo una de las estrategias,
puede ser más eficiente usar diferentes estrategias en diferentes situaciones. Silberschatz y Galvin
sugieren este enfoque:
Agrupar los recursos en un número de clases diferentes.
Usar la estrategia de ordenación lineal definida anteriormente para la prevención de círculos viciosos
de espera e impedir el interbloqueo entre clases de recursos.
Dentro de cada clase de recursos, emplear el algoritmo más apropiado para dicha clase. Como ejemplo
de esta técnica, considérense las siguientes clases de recursos:
ü Espacio intercambiable: Bloques de memoria en almacenamiento secundario para el uso en el
intercambio de procesos.
ü Recursos de procesos: Dispositivos asignables, como unidades de cinta y archivos.
ü Memoria principal: Asignable a los procesos en páginas o segmentos
ü Recursos internos: Como canales de E/S.



El orden en que se enumeran estas clases de recursos es el orden en el que se asignan. El orden es
razonable, teniendo en cuenta la secuencia de pasos que un proceso debe seguir durante su vida. En
cada clase, se pueden usar las siguientes estrategias:
ü Espacio intercambiable: puede aplicarse prevención de interbloqueo, pidiendo que todos los
recursos sean asignados de una vez, como en la estrategia de prevención de retención y espera.
Esta estrategia es razonable si se conocen los requisitos máximos de almacenamiento, lo que
suele ser habitual. Otra posibilidad es la predicción de Interbloqueos.
ü Recursos de procesos: La predicción es a menudo efectiva en esta categoría, puesto que es
razonable esperar que los procesos declaren por anticipado los recursos de esta clase que
necesitarán. También es posible en esta clase la prevención media nte la ordenación de recursos.
ü Memoria principal: la prevención con apropiación aparece por la estrategia más adecuada para
la memoria principal. Cuando se expulsa a un proceso, simplemente es trasladado a la memoria
secundaria, liberando espacio para resolver el Interbloqueo.
ü Recursos internos: puede usarse la prevención por orden de recursos.


Unidad2

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (16)

Andere mochten auch

Andere mochten auch (20)

Ähnlich wie Unidad2

Ähnlich wie Unidad2 (20)

Mehr von Universidad Autónoma de Nayarit

Mehr von Universidad Autónoma de Nayarit (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (13)

Unidad2