Tema 8 – Control de Recursos

Mecanismos de Sincronización
La sincronización entre procesos es necesaria para tareas cooperativas, con el objetivo de
cumplir restricciones lógicas en el orden de ejecución.

Existen mecanismos de sincronización entre procesos, siendo estos:

▪ Mecanismos de Bajo Nivel

➢ Espera Activa
➢ Semáforos
▪ Mecanismos de Alto Nivel
➢ Monitores
Para aquellos procesos independientes, desde un punto de vista lógico, es necesario también
establecer mecanismos de sincronización. Esto es debido a que se comparte, en mayor o menor
medida, tanto el entorno de ejecución como los recursos (que son limitados).

Ya que en tiempo real no se dispone de recursos ilimitados, debemos garantizar el correcto

acceso a los mismos mediante mecanismos de sincronización, los cuales, cumplen dos funciones
básicas:

▪ Asegurar la exclusividad de acceso a un recurso

▪ Encargarse de la planificación del uso de un recurso en función de su prioridad
Para evaluar condiciones se debe considerar la siguiente información:

▪ La operación de acceso solicitada

▪ Temporización
▪ Parámetros de la petición
▪ Estado de sincronización del recurso
▪ Estado local del recurso
▪ Historial de uso
▪ Prioridad del proceso

Mecanismos de Sincronización: Propiedades y Control de Recursos

Los requisitos que debe cumplir un mecanismo de sincronización se definen en base a tres
propiedades:

▪ Modularidad: una implementación es modular si está estructurada de tal manera que

es sencillo modificar una parte sin afectar al resto del sistema. Esta propiedad es
importante para que el sistema sea más fácil de entender y de mantener.
▪ Expresividad: un mecanismo es expresivo si permite una definición sencilla de los
requisitos de sincronización. En contraparte, un mecanismo será poco expresivo cuando
no sea posible usar la información de la que se dispone sobre el problema de
sincronización.
▪ Facilidad de uso: un sistema debe permitir la descomposición en restricciones de
sincronización individuales, que puedan ser implementadas de forma aislada. Si no
fuese así, a medida que aumenten las restricciones aumentaría la complejidad de la
implementación.
La implementación en Java del Control de Recursos se basa en el uso de monitores y métodos
sincronizados, y cumple con los requisitos de modularidad.

En función a la expresividad, un mecanismo de sincronización deberá permitir expresar

adecuadamente las restricciones de sincronización del sistema.

Las categorías de información relacionadas a los mecanismos de sincronización son:

▪ Tipo de Operación
Algunos recursos admiten distintos tipos de acceso (acceso compartido o acceso
exclusivo). Esta información puede utilizarse para dar prioridad a un tipo de acceso
frente a otro.

▪ Temporización
El orden de llegada de las solicitudes de acceso se utiliza habitualmente para gestionar
el reparto de los recursos.

Considerando únicamente este factor, un proceso que solicite un recurso antes que
otro, conseguirá el acceso en primer lugar.

▪ Parámetros
Puede ser conveniente utilizar la información contenida en los parámetros asociados a
la petición. Con frecuencia, esta información se refiere al tamaño o número de
elementos solicitados (si son recursos cuantificables), o bien a la identidad del recurso.

▪ Estado del Recurso

➢ Estado de la sincronización
Incluye toda la información del estado del recurso necesaria únicamente para
propósitos de sincronización (no sería necesaria si el recurso no se accede
concurrentemente). Contiene información sobre los procesos que tienen acceso
al recurso y las operaciones que están ejecutando.

➢ Estado local
Contiene información sobre el recurso que es necesaria, independientemente
de si el recurso se accede de forma concurrente o secuencial (buffer de
memoria).

➢ Historial de uso o acceso

Contiene información sobre los eventos ocurridos previamente en relación a un
recurso.

▪ Prioridad del Proceso

Dicha prioridad puede utilizarse para determinar el orden de acceso a los recursos.

Un proceso de mayor prioridad puede ser atendido antes que otro de menor prioridad,
a pesar de que este último haya realizado su solicitud con anterioridad al primero.

Esquemas de nombrado asimétrico/simétrico, y como afectan a la sincronización

▪ Nombrado Simétrico: una tarea servidor (o recurso protegido) siempre conoce la

identidad de la tarea cliente con la que está tratando.
 ▪ Nombrado Asimétrico: El servidor no conoce la identidad del cliente. Esto tiene como
desventaja de que pueden escribirse servidores de propósito general, pero puede dar
lugar a un problema de seguridad en relación al uso de los recursos.

Interbloqueos: en qué consisten y cuáles son las condiciones que hacen que ocurran
Los interbloqueos es una situación que se produce en el control de recursos (conocido también
como condiciones de carrera).

Cuando dos o más tareas acceden, o intentan acceder, a más de un recurso compartido, se da
la posibilidad de que se genere la situación en que los procesos involucrados queden
incapacitados para continuar su ejecución normal, bloqueándose mutuamente.

Las condiciones que hacen que esto ocurra, son:

▪ Punto Muerto (deadlock): los procesos quedan muertos esperando que los recursos
bloqueados a los que quieren acceder, queden disponibles.
▪ Bloqueo Activo (livelock): los procesos continúan su ejecución, pero no pueden
evolucionar (bucle de espera activa).
▪ Inanición (starvation): es cuando algunas tareas no obtienen recursos ya que siempre
hay otra de mayor prioridad que los están usando.
Para que se produzca un interbloqueo, deben darse, de forma simultánea, las siguientes
condiciones:

▪ Exclusión Mútua: garantiza que dos procesos no tengan acceso a un recurso al

mismo tiempo.
▪ Retención y Espera: los procesos pueden retener recursos mientras esperan a otros
recursos.
▪ No Apropiación: un proceso no puede ser expropiado de un recurso por parte del
sistema operativo, sino que tiene que cederlo voluntariamente.
▪ Esperar Circular: existe una lista circular de procesos tal que, cada uno de ellos, retiene
a un recurso solicitado por el siguiente proceso.

Estrategias para tratar los Interbloqueos

▪ Prevención
Considera la eliminación de alguna de las cuatro condiciones que provocan un
interbloqueo.

▪ Evitación
Se concede acceso a los recursos únicamente si el sistema se mantiene en un estado
seguro (un estado inseguro es aquel que puede llevar a un interbloqueo).

▪ Detección y Recuperación
Consiste en actuar después de que aparezca un estado de interbloqueo. Para ello, es
necesario detectar la ocurrencia del problema e identificar los procesos y recursos
implicados, y, a continuación, tomar las medidas necesarias para restablecer un estado
consistente.
 El algoritmo de detección, que se ejecuta de periódicamente, se basa generalmente en
técnicas de entrada en la búsqueda de esperas circulares. Una vez se ha detectado el
interbloqueo, para eliminarlo se lleva a cabo:

➢ Terminar los procesos implicados

➢ Retrocede a un estado anterior
➢ Expropiar los recursos para llegar a un estado consistente

Reencolado: en qué consiste esta función y para qué se utiliza

Consiste en mover explícitamente una tarea que se encuentra en una barrera o guarda a otra
cola de espera, donde deberá conseguir de nuevo el acceso. Se trata de una mejora en la
usabilidad en los mecanismos de evitación que proporcionan algunos lenguajes de
programación concurrente.

Un reencolado puede hacerse a la misma barrera, a otra barrera en la misma unidad, o en otra
unidad diferente.

En cuanto al flujo de control, a diferencia de lo que ocurre en una llamada a otro procedimiento,
el invocador no retoma el control.

Cuando un punto de entrada se reencola en otro, el flujo de control del primero termina. Cuando
el segundo finaliza, el control se devuelve al objeto que realizó la llamada inicial. Como
consecuencia, cuando se ejecuta un reencolado de un objeto protegido a otro, la exclusión
mutua se libera.

Clasificación de los recursos apropiativos y no apropiativos

▪ Entornos Multitarea Apropiativos

El intercambio de recursos es función de la prioridad de la tarea. Cuanto mayor es la
prioridad de una tarea, más importante es, teniendo prioridad sobre las de menor
prioridad a la hora de acceder a recursos compartidos. Compartir recursos NO puede
violar esta regla.

Si las tareas de mayor prioridad siempre toman recursos de las tareas de menor
prioridad, este esquema de intercambio no es justo, pudiendo hacer que se evite el que
se completen las tareas de menor prioridad. Esta condición se llama inanición.

La maximización de la utilización de los recursos es otro requisito conflictivo.

Un recurso apropiativo puede eliminarse de forma involuntaria y temporalmente de una

tarea sin afectar al estado de ejecución o al resultado de la tarea.
 Los registros se reinicializan para ejecutar otra tarea y, cuando se completa, el estado
de ejecución se restaura en los registros para reanudar la tarea.

El planificador debe garantizar que el conjunto de registros contenga el estado de

ejecución de la tarea, aunque los registros se compartan entre varias tareas durante
la vida útil del sistema.

▪ Entornos Multitarea NO Apropiativos

Un recurso compartido no apropiativo debe ser liberado voluntariamente por la tarea
propietaria, de lo contrario, pueden producirse resultados impredecibles.

En este caso, no se debe permitir que una tarea escriba en una región de memoria
compartida antes de que la otra tarea complete su operación de lectura o escritura.

Tipos o Modelos de solicitud de Recursos

Cuando las tareas solicitan recursos, la forma en que se realizan las solicitudes se pueden
clasificar en los siguientes modelos de solicitud:

▪ Solicitud de recurso único

Una tarea puede tener, como máximo, una solicitud de recurso pendiente en un
momento dado.

▪ Solicitud de recursos AND

Una tarea puede tener múltiples solicitudes simultáneas pendientes en cualquier
momento dado. Una tarea se bloquea hasta que disponga de todos los recursos
solicitados.

▪ Solicitud de recursos OR
Una tarea puede solicitar un conjunto de recursos, pero la tarea puede reanudar la
ejecución tan pronto como esté disponible cualquiera de los recursos del conjunto de
solicitudes.

▪ Solicitud de recursos AND-OR

Una tarea puede realizar solicitudes de recursos en cualquier combinación de los
modelos AND y OR.

Inversión de Prioridad: en qué consiste y soluciones a la misma

Es una situación en la que se ejecuta una tarea de baja prioridad mientras que, una tarea de
mayor prioridad, está esperándola debido a las retenciones de recursos. Una alta prioridad de
la tarea implica un plazo de ejecución más estricto.

La inversión de prioridad ocurre cuando existe interdependencia de tareas entre tareas con
diferentes prioridades. Para poder solucionar o tratar este problema, se emplea el uso de varios
protocolos de acceso.

Protocolos de Control de acceso que existen para tratar con la Inversión de Prioridad:
Protocolos de Herencia de Prioridad, de Prioridad Límite y de Límite de Prioridad.

▪ Protocolo de Herencia de Prioridad

 Es un protocolo de control de acceso a recursos que aumenta la prioridad de una tarea
si esta mantiene un recurso solicitado por una tarea de mayor prioridad a su mismo
nivel.

Cuando una tarea T solicita un recurso R, este protocolo sigue las reglas:

1. Si R está en uso, T está bloqueado.

2. Si R está libre, R se asigna a T.
3. Cuando una tarea de mayor prioridad solicita el mismo recurso, la prioridad de
ejecución de T se eleva al nivel de prioridad de la tarea solicitante.
4. La tarea vuelve a su prioridad anterior cuando libera R.
Este protocolo es dinámico, ya que una tarea no tiene su prioridad aumentada hasta que
una tarea de mayor prioridad realiza una solicitud del recurso compartido.

Una tarea de mayor prioridad, que no esté relacionada aún, puede expropiar a la tarea,
lo cuál es el esquema de planificación expropiativo basado en prioridades.

La promoción de la prioridad para una tarea durante la inversión de prioridad es

transitiva, es decir, la prioridad de una tarea promovida continúa aumentando incluso si
las tareas de mayor prioridad realizan solicitudes en el mismo recurso compartido
mientras se realiza la inversión de prioridad.

▪ Protocolo de Prioridad Límite

En este protocolo se conoce la prioridad de cada tarea y los recursos requeridos por
cada una de las tareas.

Para un recurso dado, el límite de prioridad es la máxima prioridad de todas las tareas
posibles que pueden requerir el recurso.

El protocolo sigue las siguientes reglas cuando una tarea T solicita un recurso R:

1. Si R está en uso, T está bloqueado.

2. Si R está libre, se asigna a T. La prioridad de ejecución de T se eleva al límite de
prioridad de R si es mayor. En cualquier momento, la prioridad de ejecución de T es
igual al límite de máxima prioridad de todos sus recursos retenidos.
3. A la prioridad de T se le asigna el siguiente límite de prioridad más alta de otro
recurso cuando se libera el recurso con el límite de prioridad más alta.
4. La tarea vuelve a su prioridad asignada después de haber liberado todos los
recursos.
La tarea hereda el techo de prioridad del recurso tan pronto como la tarea adquiere el
recurso, incluso cuando ninguna otra tarea de mayor prioridad compite por el mismo
recurso.

Esta regla implica que todas las secciones críticas de cada tarea compartida tienen el
mismo nivel de criticidad. La idea es terminar la sección crítica lo antes posible para
evitar posibles conflictos.
 Protocolo de Límite de Prioridad

En este protocolo se conoce la prioridad de cada tarea y los recursos de los que
requieren cada tarea. El límite de prioridad actual para un sistema en ejecución, en
cualquier momento, es el límite de máxima prioridad de todos los recursos en uso
en ese momento.

El protocolo sigue las siguientes reglas cuando una tarea T solicita un recurso R:

1. Si R está en uso, T está bloqueada.

2. Si R está libre se asigna a T si la prioridad de esta es mayor que el límite de
prioridad actual.
3. R se asigna a T si el límite de prioridad actual pertenece a uno de los recursos
que posee T. En caso contrario, T se bloquea.
4. La tarea que bloquea T hereda la prioridad de T si es mayor, y se ejecuta con
dicha prioridad hasta que libera todos los recursos cuyo límite de prioridad es
mayor o igual que la prioridad de T. La tarea vuelve luego a su prioridad anterior.
Como se trata en Java la Inversión de Prioridad
En Java se suelen dar dos soluciones al problema de inversión de prioridad.

▪ Herencia de la Prioridad
Para limitar la duración del bloqueo que se produce en un objeto programable
esperando un recurso, que es cuando ocurre la Inversión de Prioridad, Java en
Tiempo Real (RTSJ) requiere:

➢ Todas las colas, mantenidas por la máquina virtual en tiempo real, deben
ordenarse por prioridad. Cuando hay más de un objeto planificable en la cola
con la misma prioridad, el orden entre ellos no está definido. Del mismo
modo, las colas resultantes de las llamadas a los métodos wait en la clase
Object deben ordenarse por prioridad.
➢ Debe haber facilidades para que el programador especifique el uso de
algoritmos de control de inversión de prioridad diferentes. Por defecto, RTSJ
requiere que se produzca una herencia prioritaria cada vez que se bloquea
un objeto planificable en espera de un recurso.
El programador puede cambiar el algoritmo de control de inversión de prioridad
predeterminado para objetos individuales (o para todos los objetos) a través de la
jerarquía de clases MonitorControl.

Cada objeto planificable tiene dos prioridades asociadas:

➢ Prioridad Base: es la prioridad que tiene asignada el objeto como resultado

de sus parámetros de planificación.
➢ Prioridad Activa: es la prioridad que tiene el objeto que se está ejecutando
en ese momento, y que puede ser diferente debido a la herencia de
prioridad.
 En la planificación basada en prioridades, la elección para la ejecución se basa en la
prioridad activa en lugar de la prioridad base. El planificador elige siempre para la
ejecución el objeto planificable con la máxima prioridad activa.

Del mismo modo, todas las colas se ordenan según la prioridad activa. Sin embargo,
debe tenerse en cuenta que un objeto planificable que hereda una prioridad,
mientras está dentro de un monitor, perderá esa prioridad cuando llame al método
Object.wait, y se colocará en cola según la prioridad que tenía antes de llamar al
monitor.

▪ Mecanismos de Comunicación sin Bloqueo

RTSJ ofrece dos clases, ambas basadas en una cola, que facilitan esta forma de
comunicación.

➢ WaitFreeWriteQueue: clase destinada a situaciones en las que, un hilo en

tiempo real, sin almacenamiento dinámico, desea enviar datos a uno o más
hilos que utilizan almacenamiento dinámico. El hilo que escribe nunca se
bloquea al escribir, incluso cuando la cola está llena (la escritura falla). Los
hilos que leen pueden bloquearse cuando la cola está vacía. La clase supone
que varios hilos que escriben proporcionen su propia sincronización. Si a la
cola accede solo un hilo que lee, y solo un hilo que escribe, esa información
puede ser proporcionada por uno de los constructores. Esto permite una
implementación que optimiza el protocolo de acceso.
➢ WaitFreeReadQueue: clase destinada a situaciones en las que, un hilo en
tiempo real, sin almacenamiento dinámico, desea recibir datos de uno o más
hilos que utilizan almacenamiento dinámico. Sin embargo, puede ser
utilizado por cualquier hilo. Esencialmente, el hilo que lee nunca se bloquea
al leer, incluso cuando la cola está vacía (la lectura falla). Los hilos que
escriben pueden bloquearse cuando la cola está llena. La clase supone que
varios lectores proporcionan su propia sincronización.