a64b0469ff35958ef4ab887a898bd50bdfbbe91a-7387060

Mique Gómez Corral

Tema 1
CONCURRENCIA Y
SISTEMAS DISTRIBUIDOS

Ing. Informática ETSINF, UPV

Reservados todos los derechos.
No se permite la explotación económica ni la transformación de esta obra. Queda permitida la impresión en su totalidad.
 Tema 1
Introducción a la Programación Concurrente
Concepto de Programación Concurrente
Programa secuencial: Una única actividad (flujo de control único)

No se permite la explotación económica ni la transformación de esta obra. Queda permitida la impresión en su totalidad.
Programa concurrente: Colección de actividades (hilos) que pueden ejecutarse en paralelo. Y
cooperan para llevar a cabo una tarea común
Ejemplo: hilos auxiliares (típico en servidores). El hilo principal lanza hilos auxiliares
que realizan determinadas tareas de forma concurrente

Cómo obtener concurrencia

Podemos conseguir concurrencia de dos formas

Paralelismo lógico: un procesador con

multiprogramación

Reservados todos los derechos.

Paralelismo real: varios procesadores (ej. varios
núcleos)

Se pueden combinar ambos tipos de paralelismo

Ventajas
• Eficiencia: explota mejor los recursos máquina
• Escalabilidad: puede extenderse a sistemas distribuidos
• Gestión de las comunicaciones: explota la red. Ej: facilita el solape entre actividades de
red y resto de actividades
• Flexibilidad: resulta más fácil adaptar el programa a cambios en la especificación:
sistemas cliente servidor, juegos, dispositivos móviles…
• Menor hueco semántico: en aquellos problemas que se definen de forma natural como
una colección de actividades
• Mejora prestaciones y tolerancia a fallos: Útil en: S.O., Sistemas de bases de datos…

Inconvenientes La programación concurrente NO es fácil

• Programación delicada: hay que conocer los problemas potenciales: condiciones de
carrera interbloqueos…
• Hay que aplicar cierta disciplina en el desarrollo (existen soluciones)
• Depuración Compleja (no determinismo): Diferentes combinaciones en los hilos pueden
dar problemas que nunca más se vuelvan a repetir

¿No te llega para pagar Wuolah Pro? ¿Un año sin anuncios gratis? ¡Clic aquí!
a64b0469ff35958ef4ab887a898bd50bdfbbe91a-7387060
 Programación Concurrente en Java
Se usa java porque Los hilos forman parte del modelo del lenguaje, Dispone de primitivas para
comunicación y sincronización entre hilos y hay Bibliotecas de soporte adicionales
([Link]) para desarrollo de aplicaciones complejas

Thread (hilo) = contexto de ejecución, formado por la Máquina virtual de java, el código
(en el método run) y los datos. Todas las aplicaciones tiene un hilo principal cuando se ejecuta,
del cual pueden descender otros hilos

No se permite la explotación económica ni la transformación de esta obra. Queda permitida la impresión en su totalidad.
Crear un hilo 2 formas
Implementando la interfaz Runnable: Se ha de definir
método run() que contiene el código a ejecutar por el hilo (esto xq es
una interfaz). Luego para iniciarlo habrá que crear una instancia de la
clase Thread y iniciarla con “.start”

Extendiendo la clase Thread: Implementa Runnable y Ofrece

métodos para gestionar los hilos. Simplemente se crea el método run
para iniciarlo solo hay que crear una instancia de la misma clase en la
que estás (xq ya desciende de thread) y usar el método “.start()”

Reservados todos los derechos.

En lo general te da igual cual de los 2 métodos usar, pero ya que java solo
permite descender (extends) solo de una clase, si esa clase ya extiende de
una solo podrás implementar la interfaz

EN LA EJECUCIÓN DE HILOS DE NORMAL EL HILO MAIN NO SE CUENTA PARA CONTAR

Clases con Nombre y Anónimas

Para tener threads podemos usar 2 opciones a parte de las enteriores: nombre o anónimas

Con nombre Anónimas

Clase anónima: Java permite no crear una clase aposta para

hacer uso de los threads. No tienen nombre y solo permiten
crear un único objeto (no pueden definir constructores), estas
se definen en la misma linea de código donde se crea el objeto
de la clase y siempre dentro de otro método (como una clase
interna anidada)

¿No te llega para pagar Wuolah Pro? ¿Un año sin anuncios gratis? ¡Clic aquí!
a64b0469ff35958ef4ab887a898bd50bdfbbe91a-7387060
 Diferencia entre llamar a run() y a start()

No se permite la explotación económica ni la transformación de esta obra. Queda permitida la impresión en su totalidad.
Si llamas a start() java creará un hilo en el que se ejecutará de manera concurrente el método
run indicado, pero si ejecutas con run() también lo ejecutará pero de manera secuencial, será
el propio hilo main el que se interrumpa para meterse a ejecutar este método.

Métodos
Dependiendo de la clase si es con extends se puede poner solos los métodos, por ejemplo
“sleep()”. Pero si es con implements se tiene que añadir Thread, ejemplo “[Link]()”. Si no
te guardas la referencia a un hilo no puedes aplicar ninguno de estos métodos sobre él

• Nombre: Crearlo new T(i).start(); o en cualquier momento con setname.

[Link]("thread" + i); (i es una variable random osea le puedes poner lo que
quieras). Obtener el nombre: [Link]();

Reservados todos los derechos.

[Link]().getName();
• [Link](long millis): Suspende el método durante long milisegundo.
• [Link](): Operación que reactiva (si estaba suspendido) a un hilo y que Le
manda una excepción al hilo para que la trate “InterruptedException”.
• [Link](): Permite a un hilo (el actual) esperar a la terminación de otro hilo. Se
puede especificar un tiempo máximo de espera, con [Link](long millis). Se
puede interrumpir al hilo que espera, con el método [Link]();
• [Link](): Devuelve referencia al objeto thread que se está
ejecutando en ese momento
• [Link](): DevuelveTRUE si el hilo se ha iniciado y todavía no ha terminado y
FALSO en caso contrario
• [Link](): Abandona voluntariamente el procesador, cediendo la ejecución a
otro hilo preparado. EN EJECUCIÓN → PREPARADO

Notación Lambda
Las expresiones Lambda son funciones anónimas, y pueden ser utilizadas donde el tipo
aceptado sea una interfaz funcional (interfaz con un solo método abstracto).

Por ejemplo La interfaz Runnable es una interfaz funcional con un único método abstracto
run(). SIRVEN PARA SIMPLIFICAR EL CÓDIGO, COMPACTARLO MÁS Y EVITIAR CREAR OTRAS
CLASES

Sintaxis: (parámetros) -> {cuerpo}

El operador lambda (->) separa la declaración de parámetros de la declaración del cuerpo..

Parámetros: Cuando NO se tienen parámetros, o cuando se tienen dos o más, es necesario

utilizar paréntesis.

Cuerpo: Cuando el cuerpo de la expresión lambda tiene una única línea no es necesario
utilizar las llaves

a64b0469ff35958ef4ab887a898bd50bdfbbe91a-7387060
 Ejemplos

Creando la clase anónima y guardándonos la referencia al hilo (thread1)

No se permite la explotación económica ni la transformación de esta obra. Queda permitida la impresión en su totalidad.
Runnable task1 = () -> [Link](“Hilo #1");
Thread thread1 = new Thread(task1);
[Link](); //crear y ejecutar forma 1

Creando la clase anónima y lanzando el hilo sin guardarnos su referencia

Runnable task1
Thread= thread1
() -> [Link](“Hilo
= new Thread(task1); #1");
new Thread(task1).start(); //crear
[Link](); //crear y ejecutar
y ejecutar formaforma
1 2

Reservados todos los derechos.

Creando la clase anónima directamente en el Thread y guardándonos la referencia
Thread thread1 = new Thread(() ->
{[Link](“Hilo #1”);});
[Link](); //crear y ejecutar forma 3

Creando la clase anónima directamente en el Thread y ejecutarla sin guardar nada

new Thread(() -> [Link](“Hilo #1”)).start();
//crear y ejecutar forma 4

Lo mismo pero en este ejemplo se pone por pantalla el nombre de verdad del hilo
new Thread(() ->
[Link]([Link]().getName(),
“Hilo #1”).start(); //crear y ejecutar forma 5

¿No te llega para pagar Wuolah Pro? ¿Un año sin anuncios gratis? ¡Clic aquí!
a64b0469ff35958ef4ab887a898bd50bdfbbe91a-7387060
a64b0469ff35958ef4ab887a898bd50bdfbbe91a-7387061
Mique Gómez Corral
Tema 2
CONCURRENCIA Y
SISTEMAS DISTRIBUIDOS

Ing. Informática ETSINF, UPV

Reservados todos los derechos.
No se permite la explotación económica ni la transformación de esta obra. Queda permitida la impresión en su totalidad.
 Tema 2
Sincronización de tareas
Concurrencia paralelismo + cooperación Cooperación comunicación y/o sincronización
Condiciones de Carrera: Modificación inconsistente de la memoria compartida. Pueden
aparecer errores cuando múltiples hilos acceden a datos compartidos. Pueden aparecer

No se permite la explotación económica ni la transformación de esta obra. Queda permitida la impresión en su totalidad.
errores de vistas inconsistentes de la memoria compartida.

Tipos de Sincronización
Exclusión mutua: Solamente un hilo puede ejecutar la sección en cada momento.
Necesario para evitar interferencias entre hilo

Sincronización condicional: Un hilo debe suspenderse hasta que se cumpla

Reservados todos los derechos.

determinada condición

La condición depende del valor de alguna variable compartida. Otros hilos, al modificar esas
variables, conseguirán que se cumpla la condición, reactivando a los hilos suspendidos

Mecanismos de comunicación
Memoria compartida: Los hilos comparten espacio de memoria (variables u objetos
compartidos). Requiere mecanismos de sincronización para coordinar las tarea

Intercambio de mensajes: Emisor/Receptor potencialmente en espacios de memoria

disjuntos en los que no se comparte memoria

Esquema memoria JVM

¿No te llega para pagar Wuolah Pro? ¿Un año sin anuncios gratis? ¡Clic aquí!
a64b0469ff35958ef4ab887a898bd50bdfbbe91a-7387061
 Sección Crítica Cómo protegerla
Fragmento de código (variables globales) que puede provocar condiciones de carrera

Protocolos de entrada/salida que garantizan (en común):

1. Exclusión mutua
2. Progreso: todo servicio solicitado se completa en algún momento
3. Espera limitada: si alguien solicita en algún momento se le dejará ejecutar

No se permite la explotación económica ni la transformación de esta obra. Queda permitida la impresión en su totalidad.
Código thread-safe: Puede ser ejecutado concurrentemente por distintos
hilos de forma segura sin que se produzca ningún error de concurrencia
(por ejemplos todos los métodos tiene la cabecera synchronized)

Locks en Java Cómo implementarlos

Todo objeto posee un lock asociado implícito. Por lo que puedes crear objeto y usarlos en
los métodos syncronizeds (). Se implementa de 2 formas: en la cabecera o con una sentencia

Atomicidad: Usando locks convertimos una sección crítica en una acción atómica:
únicamente un hilo puede ejecutar el código protegido en un momento dado

Reservados todos los derechos.

Garantiza actualización fiable de variables u objetos compartidos

Synchronized en Cabecera Métodos

Etiquetar con synchronized los métodos que
forman parte de la sección crítica permite:

• Al entrar en un método etiquetado como

synchronized se cierra el lock, y al salir se abre.
• Para un mismo objeto, todos sus métodos synchronized se ejecutan en exclusión mutua
entre sí

Si tu pones synchronized en la cabecera de un método todos los hilos

que lo ejecuten estarán en exclusión mutua, y si pones varios
métodos de una clase con esa cabecera también estarán en exclusión
mutua entre ellos al ejecutarse SOLO 1 A LA VEZ

Al ejecutar un método con lock (Cerrar el lock) Al Salir de un método con lock (Abrir el lock)
• Si abierto → lo cierra • Si abierto → no tiene efecto
• Si cerrado por otro hilo → se suspende • Si cerrado por otro hilo → no tiene efecto
• Si cerrado por mismo hilo → no tiene efecto • Si cerrado por mismo hilo → se abre el lock

Si alguien espera, quedará cerrado por uno de los que esperan

Ejemplo
Los 2 métodos usan la cabecera, por lo
que solo se ejecutará uno de ellos a la
vez, y solo un hilo a la vez

¿No te llega para pagar Wuolah Pro? ¿Un año sin anuncios gratis? ¡Clic aquí!
a64b0469ff35958ef4ab887a898bd50bdfbbe91a-7387061
 Synchronized Sobre un objeto: Permite utilizar más de un lock dentro de un mismo

No se permite la explotación económica ni la transformación de esta obra. Queda permitida la impresión en su totalidad.
método y no excluir diferentes métodos

Como si fuera un mini método dentro del método. Usas

synchrinized sobre un objeto bloqueándolo, haciendo
que esa sección del código quede en exclusión mutua
PERO SOLO EN ESE MÉTODO: Esto quiere decir que si
otro hilo está ejecutando otro método del objeto con un
synchronized LO PODRÁ HACER SIN PROBLEAS

En el ejemplo Los métodos inc1 e inc2 pueden intercalarse Pero la actualización de c1 se hará
en exclusión mutua al igual que la de c2. Puede haber un hilo actualizando c1 y otro c2, pero no
2 actualizando c2 a la vez por ejemplo

Sincronización condicional

Reservados todos los derechos.

El concepto de sección crítica evita interferencias en el acceso a las variables compartidas,
pero puede surgir la necesidad de una sincronización condicional: Hacer esperar a un hilo
hasta que se cumpla una determinada condición

En el tema 3 se explica mejor, pero dejo un ejemplo ya que sale por aquí y me sobra espacio :p

En este código se pedía una solución para solucionar que

siempre que coja algo de la box haya algo y nunca se metan
cosas si está llena. Como solución se da la 4, que permite
exclusión mutua con el synchronized y con el while (!full)
permite respetar la condición

EL CÓDIGO NO ES CORRECTO 100% en vez de

[Link]() se tendría que usar la sentencia
[Link]() → TEMA 3

a64b0469ff35958ef4ab887a898bd50bdfbbe91a-7387061
a64b0469ff35958ef4ab887a898bd50bdfbbe91a-7426723
Mique Gómez Corral
Tema 3
CONCURRENCIA Y
SISTEMAS DISTRIBUIDOS

Ing. Informática ETSINF, UPV

Reservados todos los derechos.
No se permite la explotación económica ni la transformación de esta obra. Queda permitida la impresión en su totalidad.
 Tema 3
Primitivas de sincronización
Monitor
Las primitivas abrir lock y cerrar lock garantizan el acceso seguro a variables compartidas. Pero

No se permite la explotación económica ni la transformación de esta obra. Queda permitida la impresión en su totalidad.
necesitamos otras primitivas que permitan esperar de forma segura hasta que se cumpla
determinada condición lógica (sincronización). Para ello tenemos los monitores

Monitor
Un monitor es una clase para definir objetos que podemos compartir de forma segura entre
distintos hilos → Sus métodos se ejecutan en exclusión mutua y Resuelve la sincronización

Exclusión mutua: Dispone de una cola de entrada donde esperan aquellos hilos que
desean utilizar el monitor cuando lo está utilizando otro hilo. No hay condiciones de carrera
dentro del monitor

Sincronización: Podemos definir colas de espera (variables condition) dentro del monitor.

Reservados todos los derechos.

Si un hilo que ejecuta código dentro del monitor necesita esperar hasta que se cumpla
determinada condición lógica

Ejecuta [Link]() → Deja libre el monitor y espera sobre la cola de la condición c

Cuando otro hilo modifica el estado del monitor

Ejecuta [Link]() → Reactiva un hilo que espera en la cola de la condición c

Para que esto sea seguro con varios hilos la variable condition se debe comprobar con un
while(condition){ [Link](); } para que cada vez que se reactive compruebe la condición

Abstracción: Proporcionan abstracción separando su uso de su definición, el que lo crea

ignora cómo se va a usar y el que lo usa ignora como se ha implementado

Ejemplo Monitor Productor/Consumidor Pseudo Código

El objeto compartido es el buffer, con sus atributos
y métodos. Y luego Rellenamos una tabla en la que
detallamos, cada método a qué espera y a qué tiene
que avisar al hacer x cosa

Definimos una cola de espera (variable condition)

por cada caso de espera en la tabla. En el Ejemplo
condition es noLleno, noVacio. SON VARIABLES
SOBRE LAS QUE SE USAN LOS MÉTODOS DE BLOCK

¿No te llega para pagar Wuolah Pro? ¿Un año sin anuncios gratis? ¡Clic aquí!
a64b0469ff35958ef4ab887a898bd50bdfbbe91a-7426723
 Monitores en Java
Dos niveles posibles, uno es el Soporte básico en el lenguaje y el otro el Soporte extendido
mediante la biblioteca [Link]. En este tema solo Soporte Básico

Todo objeto posee de forma implícita (sin necesidad de declararlos) Un lock y Una cola de
espera con primitivas. CADA OBJETO TIENE LA SUYA, por lo que pueden haber 2 hilos y cada
uno en una cola diferente

Lock: Al etiquetar un método con synchronized, se garantiza ejecución en exclusión mutua.

No se permite la explotación económica ni la transformación de esta obra. Queda permitida la impresión en su totalidad.
Esto equivale a cerrar lock al entrar y abrir lock tras la última instrucción, al salir.

Cola de espera: Con 3 primitivas

• wait() Espera sobre la cola de espera a que alguien le notifique (deja libre el lock)
• notify() Reactiva (Notifica) a uno de los hilos que esperan en dicha cola
• notifyAll() Reactiva (Notifica) a todos los hilos que esperan

SI SOLO HAY 2 HILO CON notify(); VAS BIEN, SI HAY MÁS EN JAVA NECESITAS notifyall();

Así NO podemos declarar otros locks ni otras colas de espera. El monitor de Java sigue el
modelo de Lampson-Redell

Reservados todos los derechos.

Clases cómo Monitor Debe cumplir estos requisitos (cosa del programador)
• Definir todos sus atributos como privados
• Sincronizar todos sus métodos no privados (synchronized)
• En implementación de cada método, acceder sólo a atributos de la clase y variables locales
• Utilizar wait(), notify(), notifyAll() dentro de métodos sincronizados

Monitor Teórico: Los hilos que esperan por condiciones lógicas distintas esperan en
colas de espera distintas, cada una con una condición diferente Ej: noVacio o noLleno

Monitor Java: Java utiliza únicamente una variable condición por monitor. Por lo que hilos
que esperan por condiciones lógicas distintas esperan en una única cola, no en diferentes.

Por lo que al reactivar un hilo no sabemos si reactivamos al que esperaba por una condición o
por otra. Excepto en casos muy simples con 2 hilos por ejemplo, se recomienda despertar a
todos y que cada uno vuelva a comprobar su condición

Estructura básica de un monitor

¿No te llega para pagar Wuolah Pro? ¿Un año sin anuncios gratis? ¡Clic aquí!
a64b0469ff35958ef4ab887a898bd50bdfbbe91a-7426723
 Variantes del Monitor

No se permite la explotación económica ni la transformación de esta obra. Queda permitida la impresión en su totalidad.
Los monitores garantizan la Exclusión Mutua, osea que Sólo un hilo ejecuta código del monitor
en un instante dado

Ejemplificación del problema

Cuando el hilo activo (W) en el monitor ejecuta [Link](), pasa a
esperar sobre “c”

El monitor queda libre (espera fuera de la SC) por lo que Otro hilo (N)
que espera en la entrada pasa a activo en el monitor

Problema: Si el hilo N ejecuta [Link]() Reactiva a W. Pero

sólo uno (W o N) puede continuar activo en el monitor. Ya que los 2
estarían dentro del código, a la vez, hay que tener un criterio para solucionar esto

Reservados todos los derechos.

Se proponen 2 modelos para solucionar esto: Modelo Hoare y Modelo Lampson-Redell (hay +)

Monitor tipo Hoare Se añade una cola especial para procesos que despierten a otros
Supongamos que W espera en cond c y N ejecuta [Link]() reactivando W.
→ El hilo N pasará a una cola especial, la cual es más prioritaria que la normal,
mientras que W se queda activo ejecutando el código. SE LE DA PRIORIDAD AL
HILO DESPERTADO

De esta manera se cumple exclusión mutua sobre la zona deseada

Monitor tipo Lampson-Redell Modelo usado por java

Supongamos que W espera en cond c y N ejecuta [Link]() reactivando W.
→ Ahora W pasará a la Cola de Entrada mientras que N se quedará activo
ejecutando el código. No crea ninguna cola extra ni nada, lo mete a la cola
normal, pero cuando entre volverá al punto del código donde se había quedado
SE LE DA PRIORIDAD AL HILO NOTIFICADOR

Tendrá que volver a evaluar la condición por si ha cambiado (Con while)

Invocaciones cruzadas Entre diferentes Monitores

Invocar desde un monitor a un método de otro monitor puede: Reducir la concurrencia y
incluso provocar interbloqueos

Ejemplo: H1 en Ma y H2 en Mb
H1 activo en Ma, invoca un método de Mb, dentro del cual ejecuta
[Link]() y Libera el monitor Mb, pero no Ma (Nadie más puede usar
Ma mientras H1 espera en Mb, por lo que reducimos la concurrencia)

Si H2 entra en Mb (que estaba libre) e invoca un método del monitor Ma Espera en la cola de
entrada de Ma (Ma está ocupado aún por H1), este NO PUEDE EJCUTAR, se suspende en la
cola de Ma por lo que No deja libre el monitor Mb y Hemos llegado a un interbloqueo

a64b0469ff35958ef4ab887a898bd50bdfbbe91a-7426723
a64b0469ff35958ef4ab887a898bd50bdfbbe91a-7507703
Mique Gómez Corral
Tema 4
CONCURRENCIA Y
SISTEMAS DISTRIBUIDOS

Ing. Informática ETSINF, UPV

Reservados todos los derechos.
No se permite la explotación económica ni la transformación de esta obra. Queda permitida la impresión en su totalidad.
 Tema 4
Interbloqueos
Conceptos
Recurso: Cualquier elemento físico o lógico que solicita un hilo (impresora E/S, semáforo, ...)

No se permite la explotación económica ni la transformación de esta obra. Queda permitida la impresión en su totalidad.
Estos pueden tener varias instancias las cuales son equivalentes para el hilo: Si pides imprimir
algo te da igual si es en la impresora 1 que en la 15

Un hilo A espera a otro hilo B cuando solicita un recurso usado por B y dicho recurso no es
compartible (no pueden usarlo ambos a la vez) EXCLUSIÓN MUTUA

Protocolo
1. Petición: Si no está disponible hilo se suspende hasta que lo esté (a la puta cola se va)
2. Uso: Usa el puto recurso.
3. Liberación: Deja usar el puto recurso y el si había algún subnormal esperando lo usa

Interbloqueo: Existen hilos que no pueden evolucionar porque se esperan mutuamente

Reservados todos los derechos.

Condiciones de Coffman
Cuatro condiciones necesarias para que se de un interbloqueo

1. Exclusión mutua: Mientras un recurso está asignado a un hilo, otros no pueden usarlo
2. Retención y espera: Los recursos se solicitan a medida que se necesitan, de forma que
podemos tener un recurso asignado y solicitar otro no disponible (espera)
3. No expulsión: Un recurso asignado sólo lo puede liberar su dueño (no expropiable)
4. Espera circular: En el grupo de hilos interbloqueados, cada uno está esperando un
recurso que mantiene otro del grupo, y así sucesivamente hasta cerrar el círculo-

Sentencias que SEGURO que los desgraciados preguntan en el examen AAAAAAAAAAAAHH

• Si todas se cumplen simultáneamente, riesgo de interbloqueo
• Las de arriba Son condiciones necesarias pero no suficientes: Se necesitan todas, pero
lo estar NO NECESARIAMENTE TIENE QUE HABERLO
• En caso de interbloqueo, se cumplen todas.

Representación Gráfica grafo de asignación de recursos (GAR)

• Círculo: Representa al hilo o proceso
• Rectángulo: Representa al recurso (Contiene tantos puntos como instancias el recurso)
• Arista de asignación: Un recurso asignado es una flecha desde una instancia
concreta al hilo que la utiliza
• Arista de petición: Una solicitud no resuelta (no hay instancias libres del recurso, el
hilo debe esperar) flecha que va desde el hilo al recurso (y no a una instancia concreta)

¿No te llega para pagar Wuolah Pro? ¿Un año sin anuncios gratis? ¡Clic aquí!
a64b0469ff35958ef4ab887a898bd50bdfbbe91a-7507703
 Solicitud

No se permite la explotación económica ni la transformación de esta obra. Queda permitida la impresión en su totalidad.
Análisis del GAR
Interbloque: Un ciclo dirigido en el GAR implica riesgo de interbloqueo. Si todos los
recursos que participan en el ciclo tienen una única instancia y el ciclo dirigido, entonces
tenemos un interbloqueo. Si tiene más de 1 instancia hay RIESGO, pero no 100% Interbloqueo

Si existe un interbloqueo, seguro que hay un ciclo dirigido en el GAR

Secuencia segura: Si encontramos un orden en que puedan terminar todos los hilos
(secuencia segura), significa que no hay interbloqueo

Reservados todos los derechos.

En el ejemplo, en la imagen derecha NO HAY ORDECN SEGURO por lo que habrá interbloqueo

Para poder encontrar la secuencia segura mirar procesos que tengan todos sus recursos
asignados y puedan continuar, vas descartando y si terminas todo bien. Pero si no llegas a un
punto donde todos los procesos NO tienen asignados todos los recursos (esperar) interblock

Soluciones 4 en total puestas de MEJOR a PEOR

1. Prevención: Diseñar un sistema que rompa alguna Condición de Coffman. El
interbloqueo NO es posible, ya que son las 4 SON NECESARIAS (no suficientes)
2. Evitación: El sistema, usando un GAR, considera cada solicitud y decide si es seguro
atenderla en ese momento.
o Si una solicitud crea un ciclo (riesgo de interbloqueo), deniega esa solicitud
(algoritmo del banquero). No puede llegar a interbloqueo, pero requiere
comprobar cada solicitud y puede ser costoso.
3. Detección y recuperación: Monitoriza periódicamente el sistema. Si hemos
llegado a una situación de interbloqueo, aborta alguna(s) de las actividades
4. Ignorar el problema: No resuelve nada, pero es una postura cómoda y
frecuente. Muchos Sistemas Operativos utilizan esta solución, como Unix y Windows

¿No te llega para pagar Wuolah Pro? ¿Un año sin anuncios gratis? ¡Clic aquí!
a64b0469ff35958ef4ab887a898bd50bdfbbe91a-7507703
 Estrategias de prevención

No se permite la explotación económica ni la transformación de esta obra. Queda permitida la impresión en su totalidad.
La prevención implica que se rompa alguna de las condiciones de Coffman, miremos las 4

Exclusión mutua: Depende del sistema, pero muchas veces la mayor parte de recursos
deben usarse en exclusión mutua (recursos no compartibles) No se puede hacer nada

Retención y espera: La forma normal de trabajar es solicitar recursos a medida que los
necesitamos, lo que conduce a retención y espera. }

• Solución 1: Pedir desde el principio todo lo que podemos llegar a necesitar, esperar
hasta tenerlo.
• Solución 2: Solicitar recursos de forma no bloqueante. Si el recurso está en uso, el
hilo no se bloquea, sino que recibe un valor que indica dicha situación. El hilo libera
aquellos recursos que ha retenido.

Reservados todos los derechos.

Problemas
• Reducen drásticamente la concurrencia: Muchos hilos tienen que esperar, o bien hay
que reintentar repetidamente las reservas.
• Baja utilización de los recursos: Pueden provocar inanición, los hilos que pidan mucho
recursos solicitados con frecuencia por otros hilos, nunca los tienen todos a la vez

No expulsión: Permitimos que un hilo expropie recursos de otro. El hilo expropiado

tendría que volver a solicitar recursos (mayor coste). Podríamos tener a varios hilos que no
avanzan porque se están expropiando mutuamente recursos y nadie llega a tener todo el
conjunto que necesita (livelock) → Para ello hay que asignar diferentes prioridades

Espera circular: Establecemos un orden total entre los recursos, y obligamos a solicitar los
recursos en orden. Suele ser la condición más fácil de romper

a64b0469ff35958ef4ab887a898bd50bdfbbe91a-7507703
a64b0469ff35958ef4ab887a898bd50bdfbbe91a-7568768
Mique Gómez Corral
Tema 5
CONCURRENCIA Y
SISTEMAS DISTRIBUIDOS

Ing. Informática ETSINF, UPV

Reservados todos los derechos.
No se permite la explotación económica ni la transformación de esta obra. Queda permitida la impresión en su totalidad.
 Tema 5
Otras herramientas de sincronización
Biblioteca [Link]
Ofrece construcciones de alto nivel que incluyen herramientas y Garantizan

No se permite la explotación económica ni la transformación de esta obra. Queda permitida la impresión en su totalidad.
• Productividad: Facilita desarrollo/mantenimiento de aplicaciones concurrentes de
calidad
• Prestaciones: Más eficiente y escalable que las implementaciones típicas
• Fiabilidad: Comprobaciones extensivas contra interbloqueos, condiciones de carrera,
inanición

Herramientas: Locks, Variables condición, Colecciones concurrentes, Variables atómicas,

de Sincronización: Semáforos y Barreras, Entorno para la gestión de hilos (Executor)

Locks

Reservados todos los derechos.

[Link] proporciona diferentes clases e interfaces para la gestión y
desarrollo de múltiples tipos de locks

Características
• Permite especificar si se requiere una gestión equitativa (atributo fair para evitar
inanición) de la cola de espera mantenida por el lock
• Se facilitan distintos tipos de locks, con semántica diferente como por Ejemplo: locks
orientados a exclusión mutua, locks que resuelven el problema de lectores-escritores, ya
que puedes especificarlo solo entre escritores y solo entre lectores en vez de los 2 a la vez.
• Ofrece un método tryLock() que no suspende al invocador si el lock ya ha sido cerrado
por otro hilo: Se rompe así la condición de retención y espera (Condiciones de Coffman)

ReentrantLocks
Es una clase ofrecida, la clase ReentrantLock, Esta Implementa un lock reentrante: Dentro de la
sección de código protegida por el lock se podrá volver a utilizar ese mismo lock sin que haya
problemas de bloqueo.

Resuelve las limitaciones de la sentencia 'synchronized’

• Permite especificar un plazo máximo de espera para obtener el lock → tryLock() con
timeout.
• Definir distintas variables condición → método newCondition()
• Cerrar y abrir los locks en diferentes métodos de la aplicación → lock(), unlock(): No
restringe el uso de los objetos lock a la construcción de monitores.
• Soporte para interrupciones sobre hilos que esperan adquirir un lock, Se pueden
interrumpir las esperas usando [Link]()
• Antes no podías consultar el estado del monitor antes de acceder, ahora sí (trylock())

¿No te llega para pagar Wuolah Pro? ¿Un año sin anuncios gratis? ¡Clic aquí!
a64b0469ff35958ef4ab887a898bd50bdfbbe91a-7568768
 Inconveniente: Ahora los loks NO SE ABREN AUTOMATICAMENTE, por lo que hay que
hacerlo de manera manual unlock(). HAY Q HACER TANTOS UNLOCK COMO LOCKS HECHOS

Estructura recomendada

No se permite la explotación económica ni la transformación de esta obra. Queda permitida la impresión en su totalidad.
Variables condición
La interfaz Condition permite declarar cualquier número de variables condición en un lock, En
muchos casos utilizar múltiples variables condición permite un código más legible y eficiente
como por ejemplos en los casos de productor/consumidor (una condición para cada uno)

Reservados todos los derechos.

Restricción: El objeto lock actúa como una factoría para variables condición asociadas al
mismo. Sólo podemos definir variables condición dentro de un lock

Crear condición: Método newCondition() de la clase ReentrantLock permite generar

todas las colas de espera (condiciones) que necesarias y devuelve un objeto que implanta la
interfaz Condition

Métodos de la interfaz Condition

• await(): Suspende a un hilo en la condición
• signal(): Notifica a uno de los hilos que estuviera esperándolo
• signalAll(): Notifica a todos los hilos suspendidos en la condición

En los monitores básicos, los métodos similares son wait(), notify(), notifyAll() pero estos
actúan sobre el objeto correspondiente, los otros sobre el lock asociado a la condición

Ejemplo Lock y condition

Consumidor productor

¿No te llega para pagar Wuolah Pro? ¿Un año sin anuncios gratis? ¡Clic aquí!
a64b0469ff35958ef4ab887a898bd50bdfbbe91a-7568768
 Colecciones concurrentes
[Link] incluye versiones Thread-safe de las EDAs que hay en java.

Clases ConcurrentHashMap, ConcurrentSkipListMap, implantando la interfaz Map.

CopyOnWriteArrayList, para meter la interfaz List o Interfaz BlockingQueue, extiende Queue.

Implementaciones concurrentes eficientes de Queue

• ArrayBlockingQueue

No se permite la explotación económica ni la transformación de esta obra. Queda permitida la impresión en su totalidad.
• ConcurrentLinkedQueue
• LinkedBlockingQueue
• PriorityBlockingQueue
• DelayQueue
• SynchronousQueue

Ejemplo BlockingQueue productor/consumidor

Reservados todos los derechos.

La implementación condicional viene ya en las clases que se usan, no hace falta implementarla

Variables atómicas
Package [Link] Proporciona instrucciones que el compilador java hará en
una sola instrucción y no las descompondrá en otras sub instrucciones, asegurando que
durante su tiempo de ejecución los valores tratados no cambien (EXCLUSIÓN MUTUA DE
VALORES → GARANTIZAR LA EJECUCIÓN NO INTERRUMPIBLE lo que veíamos en FSO)

Acceso concurrente seguro a variables simples

Ejemplo: La instrucción i++ no es atómica, se descompone en subintrucciones, pero

AtomicInteger posee una operación de incrementación atómica

Útil para: implementar algoritmos concurrentes de forma eficiente, implementación de

contadores o generadores de secuencias de números. Esto es mejor que con SYNCHRONIZED

¿No te llega para pagar Wuolah Pro? ¿Un año sin anuncios gratis? ¡Clic aquí!
a64b0469ff35958ef4ab887a898bd50bdfbbe91a-7568768
 Métodos y clases más importantes

No se permite la explotación económica ni la transformación de esta obra. Queda permitida la impresión en su totalidad.
• AtomicLong → Permite actualizar de forma atómica un valor long con algunos métodos
• addAndGet() → atómicamente añade el valor dado al actual
• decrementAndGet(), getAndDecrement() → atómicamente decrementa en 1

Reservados todos los derechos.

• incrementAndGet(), getAndIncrement() → atómicamente incrementa en 1
• getAndSet(), compareAndSet(), toString()…

Ejemplo
Clase normal Con AtomicLong

Sincronización
Semáforos
La clase Semaphore permite la sincronización entre hilos. Se usan los métodos acquire() y
release().

• acquire(): Espera hasta disponer de un permiso, y entonces lo consume

• release(): Añade un permiso, y posiblemente libera a un hilo esperando tras acquire()
Acquiere() “adquiere” un permiso sobre el semáforo (si hay permisos, entra y sinó se espera)
mientras que reléase() lo libera, si hay otro esperando le deja el permiso.

El número de “permisos” (hilos que puede usar un

semáforo) se ha definir en el constructor

a64b0469ff35958ef4ab887a898bd50bdfbbe91a-7568768
 Semáforos como los mutex (semáforos con entrada a 1 solo hilo) se pueden usar para
proteger secciones críticas o para sincronizar hilos. Cada semáforo lleva asociado un contador
que se inicializa en la creación este contador si:

• Se inicializan a 1 garantiza exclusión mutua

• Se inicializan a valor positivo > 𝟏 limita el grado de concurrencia
• Se inicializan a 0 garantiza cierto orden de ejecución entre dos o más hilos
Semaphore sem = new Semaphore(n, true);

No se permite la explotación económica ni la transformación de esta obra. Queda permitida la impresión en su totalidad.
El true indica si se hace con colas equitativas FIFO

Ejemplos
Inicializado a 0 Ejemplo de sincronización de hilos
Semaphore sem = new Semaphore(0, true);

Reservados todos los derechos.

Barreras
Permiten sincronizar a múltiples hilos de ejecución. En [Link] existen dos tipos
diferentes de barreras: CyclicBarrier y CountdownLatch

CyclicBarrier
Permite que varios hilos se esperen mutuamente en un punto, Se abre cuando determinado
número de hilos llega a la barrera

• Await(): El Método await() de la barrera suspende al hilo que lo invoca

• Cuando último hilo invoca await(), la barrera se abre y los hilos se reactivan

Reutilizable: Es reutilizable (por eso se dice que es cíclica) → Al abrirse y pasar los
hilos, se restauran las condiciones iniciales

Ideal para aplicaciones iterativas Ej: en cada iteración un hilo trabajador (Worker)
procesa una columna de la matriz, y un coordinador (Solver) mezcla los resultados

Nº de hilos que esperarán

en la barrera

Opcional: Tarea a realizar,

por el último hilo que llegue,
cuando la barrera se abre
(antes de reactivar los hilos)

¿No te llega para pagar Wuolah Pro? ¿Un año sin anuncios gratis? ¡Clic aquí!
a64b0469ff35958ef4ab887a898bd50bdfbbe91a-7568768
 CountDownLatch
Permite suspender a un grupo de hilos, a la espera de que suceda algún evento generado por
un hilo ajeno al grupo. Se mantiene un contador de eventos, inicializado en el constructor

await(): Los hilos se bloquean en la barrera mientras esté cerrada

countDown(): decrementa en 1 el valor del contador (si superior a cero).

Si contador pasa a 0 la barrera se abre, liberando todos los hilos

No se permite la explotación económica ni la transformación de esta obra. Queda permitida la impresión en su totalidad.
Barrera de un solo uso: Una vez a cero, permanece así. Si se desea
reutilización, usar CyclicBarrier (que se reinicia y pone todo de nuevo)

Se pone un número en el constructor, ese es el número de veces que hay

que hacer countdown() para liberar la barrera y que pasen todos los hilos que se esperen

startSignal: para que

doneSignal: donde todos los Worker
Driver espera a que

Reservados todos los derechos.

comiencen a la vez
todos los Worker
finalicen su trabajo.

Entorno para la gestión de hilos (Executor)

La creación de hilos es una operación costosa, que requiere muchos recursos y puede resultar
lenta. La Interfaz Executor ofrece un entorno para la creación y gestión de hilos en Java:
Permite su invocación, planificación, ejecución y control de políticas de ejecución.

Ventajas
• Previene el consumo desmedido de recursos
• Biblioteca ya implementada (Executor) para crear tareas de una forma muy flexible

Interfaz Executor
La interfaz Executor ofrece la subinterfaz ExecutorService, que permite crear diferentes tipos
de Executors

Un hilo único (SingleThreadExecutor): Utiliza un solo hilo de trabajo que opera en

una cola sin límites. Se garantiza que las tareas se ejecutan de forma secuencial, y que no
habrá más de una tarea activa en un momento dado. El Código crea un solo hilo en el que las
tareas quedan en cola y se ejecutan de forma secuencial
ExecutorService executorService1 = [Link]();

Un thread-pool: Permite mantener un conjunto de hilos ya creados, reciclándolos para

que ejecuten nuevas tareas. El Código crea un pool con 10 hilos

ExecutorService executorService2 = [Link](10);

¿No te llega para pagar Wuolah Pro? ¿Un año sin anuncios gratis? ¡Clic aquí!
a64b0469ff35958ef4ab887a898bd50bdfbbe91a-7568768
 Ejemplo

No se permite la explotación económica ni la transformación de esta obra. Queda permitida la impresión en su totalidad.
Asignación de tareas
Existen diferentes formas para delegar tareas para la ejecución de un ExecutorService:
execute(Runnable), submit(Runnable), submit(Callable), invokeAny(…), invokeAll(…)

Reservados todos los derechos.

Por defecto, ExecutorService se queda “escuchando” nuevas tareas. Queda activo para recibir
nuevas tareas. Aunque acabe el hilo main, ExecutorService continúa activo

Detener el ExecutorService
Existen dos formas para detener el ExecutorService: shutdown() y shutdownNow()

shutdown(): Permite detener los hilos del Executor. No se detiene inmediatamente, pero
ya no aceptará nuevas tareas. Cuando todos los hilos hayan acabado con sus tareas actuales,
entonces se detendrá

shutdownNow(): Trata de detener todas las tareas en ejecución. Las tareas presentadas
pero no procesadas las ignora. Intenta parar las tareas en ejecución (aunque algunas podrían
ejecutarse hasta su finalización). Devuelve la lista de tareas que no finalizaron

Cosos importantes
• Aunque el hilo principal (main) de la aplicación termine, el ExecutorService continuará
ejecutándose (y, por tanto, la aplicación), mientras esté activo.
• Podemos utilizar awaitTermination() para esperar a que ExecutorService se detenga.

¿No te llega para pagar Wuolah Pro? ¿Un año sin anuncios gratis? ¡Clic aquí!
a64b0469ff35958ef4ab887a898bd50bdfbbe91a-7568768
a64b0469ff35958ef4ab887a898bd50bdfbbe91a-7568767
Mique Gómez Corral
Tema 6
CONCURRENCIA Y
SISTEMAS DISTRIBUIDOS

Ing. Informática ETSINF, UPV

Reservados todos los derechos.
No se permite la explotación económica ni la transformación de esta obra. Queda permitida la impresión en su totalidad.
 Tema 6
Sincronización en Sistemas de Tiempo Real
Introducción a los Sistemas de Tiempo Real STR
Un sistema de tiempo real (STR) es un sistema informático que Interacciona repetidamente

No se permite la explotación económica ni la transformación de esta obra. Queda permitida la impresión en su totalidad.
con su entorno físico, Responde a los estímulos dentro de un plazo de tiempo determinado,

Para que el funcionamiento del sistema sea correcto no basta con que las acciones sean
correctas, sino que tienen que ejecutarse dentro del intervalo de tiempo especificado

El tiempo en que se ejecutan las acciones del sistema es significativo

Requisitos de tiempo real frecuentes: Realizar actividades periódicas solicitadas a
intervalos periódicos, deben completar un trabajo antes de un plazo

Un sistema con varios computadores, hardware E/S, y software con cierto propósito, este
interacciona con el entorno de manera que ha de reaccionar con cierto tiempo a la vez a
todos los estímulos que reciba (simultaneidad). Como resultado se imponen requisitos

Reservados todos los derechos.

temporales sobre el software, este es de naturaleza concurrente

Ejemplo
El sistema de tiempo real actúa sobre el
sistema controlado para conseguir que tenga
un comportamiento determinado

Actúa de manera realimentada: Manda

una orden, pasa algo que cambia el estado, lo
detecta, procesa y manda otra orden… así todo el
rato

Entorno de un sistema de tiempo real

Un SRT debe responder a los estímulos de su entorno dentro de un intervalo de tiempo
determinado por las propiedades dinámicas del entorno

Estímulo y respuesta: El intervalo de

respuesta se caracteriza por un plazo Deadline
Según lo que pase si se superar este deadline
tenemos 3 opciones

• Estricto o crítico (hard): Una respuesta fuera de plazo es inadmisible. Ejemplo: UCI,
central nuclear, control de frenado, airbag …
• Firme (firm): Una respuesta fuera de plazo no tiene utilidad. Ejemplo: En sistemas
multimedia, procesado de audio o víde, la pérdida de una trama de audio o vídeo)

¿No te llega para pagar Wuolah Pro? ¿Un año sin anuncios gratis? ¡Clic aquí!
a64b0469ff35958ef4ab887a898bd50bdfbbe91a-7568767
 • Flexible (soft): Una respuesta fuera de plazo tiene una utilidad reducida. Ejemplo:
adquisición de datos meteorológicos, contestador automático

Características de los STR

Concurrencia
Los componentes del sistema controlado funcionan simultáneamente, El STR debe atenderlo
y generar las acciones de control simultáneamente

No se permite la explotación económica ni la transformación de esta obra. Queda permitida la impresión en su totalidad.
Interacción con dispositivos físicos
Los STR interaccionan con su entorno mediante diversos tipos de dispositivos no
convencionales: Convertidores A/D y D/A, entradas y salidas digitales, sensores…

Los componentes del software que controlan el funcionamiento de estos dispositivos

(manejadores o "drivers") son, en general, dependientes del sistema concreto

Fiabilidad y seguridad
Un fallo en un sistema de control puede hacer que el sistema controlado se comporte de
forma peligrosa o antieconómica. Hay que asegurar que si el sistema de control falla lo haga

Reservados todos los derechos.

de forma que el sistema controlado quede en un estado seguro

Hay que tener en cuenta los posibles fallos o excepciones en el diseño

Determinismo Temporal
Acciones en intervalos de tiempo determinados. Es fundamental que el comportamiento
temporal de los STR sea determinista. No es lo mismo que sea eficiente, solo que debe
responder correctamente en todas las situaciones. Prever el comportamiento en el peor caso.

Características específicas: Las características específicas de los sistemas de tiempo real

críticos condicionan los métodos y herramientas que se utilizan para desarrollar el software
No todas las técnicas que se usan para construir otros tipos de sistemas sirven para el software
de tiempo real crítico ya que suele haber problemas de fiabilidad y determinismo temporal

Predictibilidad
La predictibilidad es uno de los objetivos principales en sistemas de tiempo real. Se debe
realizar un análisis de la planificabilidad de las tareas de un sistema de tiempo real para
predecir si las tareas cumplirán sus requisitos temporales

Planificación de tareas en STR

El Objetivo es Planificar el uso de los recursos del sistema (en particular el procesador), para
poder garantizar los requisitos temporales de las tareas Tarea = Actividad = Hilo

Paradigma de planificación Proporciona 2 elementos

• Un algoritmo de planificación que determina el orden de acceso de las tareas a los
recursos del sistema
• Un método de análisis que permite calcular el comportamiento temporal del sistema

¿No te llega para pagar Wuolah Pro? ¿Un año sin anuncios gratis? ¡Clic aquí!
a64b0469ff35958ef4ab887a898bd50bdfbbe91a-7568767
 Para comprobar que los requisitos están garantizados en todos los casos se estudia siempre
el peor caso. Es necesario conocer la duración de las tareas en el peor caso

Algoritmo: Planificación por prioridades fijas expulsivas

La prioridad, además de un mecanismo, es un atributo de las tareas normalmente ligado a su
importancia relativa en el conjunto de tareas. En las STR esta planificación es la más popular

• El comportamiento temporal es más fácil de entender y predecir

• El tratamiento ante sobrecargas es fácil de prever

No se permite la explotación económica ni la transformación de esta obra. Queda permitida la impresión en su totalidad.
• Existen técnicas analíticas completas
• Requerido por estándares de sistemas operativos y lenguajes concurrentes

Prioridades Fijas: Prioridad permanece constante durante viva la terea

Ejecución: En la planificación por prioridades se ejecuta siempre la tarea más prioritaria
Expulsiva: Si una tarea más prioritaria a la que se está ejecutando entra en preparado,
expulsa a la que hay y empieza a ejecutares.

Análisis de STR Modelo de tareas

Reservados todos los derechos.

Para poder organizar un conjunto de tareas y ver si es panificable, o sea que se pueden
ejecutar cumpliendo todos los requisitos temporales y toda la vaina, hay que asumir algunas
cosas y crear un MODELO. Sin estas restricciones no sería posible predecir su comportamiento
Esto es necesario para predecir su comportamiento en el caso más desfavorable

• Las tareas son fijas: estáticas, no se crean dinámicamente (en tiempo de ejecución).
A este conjunto se le llama 𝜏 = {𝜏1, 𝜏2. . . , 𝜏𝑛}
• Tareas periódicas: su periodo se 𝒍𝒍𝒂𝒎𝒂 𝑻𝒊. Existe un Hiperperiodo, que es cuando
todas las tareas coinciden/terminan un ciclo, es el mínimo común múltiplo de todos los Ti.
• No cooperan entre sí: no comparten objetos ni cosas (son independientes)
• T de ejecución máximo: Se conoce el tiemp. de ejecución máximo de cada 𝒕𝒂𝒓𝒆𝒂 𝑪𝒊
• Plazo de respuesta: Cada tarea tiene un este plazo menor a su periodo 𝑫𝒊 ≤ 𝑻𝒊
Respecto a la ejecución de las tareas, asumimos que

• Expulsiva por prioridades: La política de planificación es expulsiva por prioridades.

• Dedicada a la aplicación: La máquina está dedicada a la aplicación
• Cambios de contexto: Los cambios de contexto tienen coste cero.
• No suspenderse: Las tareas no pueden suspenderse voluntariamente. Una vez una
tarea está preparada, no puede demorar su ejecución

Cronograman de tareas periódicas

¿No te llega para pagar Wuolah Pro? ¿Un año sin anuncios gratis? ¡Clic aquí!
a64b0469ff35958ef4ab887a898bd50bdfbbe91a-7568767
 Se usan para ver la planificabilidad de un conjunto de tareas. Para hacerlos hay 3 elementos.

No se permite la explotación económica ni la transformación de esta obra. Queda permitida la impresión en su totalidad.
Primero se ordenan de más prioritario a menos prioritario las taras (de arriba abajo). Los
rectángulos el tiempo que está en ejecución y luego el ^ y el ⃝ te lo pongo bajo.

𝑝𝑟𝑖(1) > 𝑝𝑟𝑖(2) > 𝑝𝑟𝑖(3)

Los cronogramas se han de extender
hasta que se llegue al Hiperperiodo y
todas las tareas coincidan de nuevo, o
hasta que no se cumpla una deadline.

Principios básicos
Ya que el objetivo es ver si al ejecutarse todas las tareas se cumplen con las deadline, hay una
manera para encontrar el peor caso de tareas periódicas independientes.

Reservados todos los derechos.

Instante crítico: El tiempo de respuesta de peor caso de todas las tareas se obtiene si las
activamos todas a la vez, o tiene un momento conde se activan todas a la vez. Esto es ya que el
tiempo de respuesta del procesador es máximo, por lo que también lo es el de las tareas.

Basta comprobar el primer plazo: Después de un instante crítico, si una tarea

cumple su primer plazo cumplirá todos los plazos posteriores. Esto quiere decir ejecutarlo
hasta el Hiperperiodo, donde todo se repita otra vez. Si se hace bien 1 vez lo hará todas

Basándose en estos conceptos se obtiene el test de planificabilidad:

Test exacto, o de tiempos de respuesta
Ecuación del tiempo de respuesta
El tiempo de respuesta de una tarea es la suma de su tiempo de cómputo más la interferencia
que sufre por la ejecución de tareas más prioritarias

𝑅𝑖 = 𝐶𝑖 + 𝐼𝑖

Interferencia máxima: Interferencia máxima que causa una tarea de mayor prioridad “j”
sobre otra de menor prioridad “i”.

Para eso hay que Acumular el tiempo en el que la tarea “j” está en ejecución mientras se
ejecuta “i”. Y tenemos que para sacar el número de veces que se activa “j” durante “i” hay que
dividir el tiempo durante el que vive “i” y dividirlo entre
cada cuanto se activa “j”

𝑅𝑖
= 𝑁ú𝑚𝑒𝑟𝑜 𝑑𝑒 𝑎𝑐𝑡𝑖𝑣𝑎𝑐𝑖𝑜𝑛𝑒𝑠 𝑑𝑒 𝑗 𝑒𝑛 𝑅𝑖
𝑇𝑗

a64b0469ff35958ef4ab887a898bd50bdfbbe91a-7568767
 Si ya tienes el número de veces que se activa “j” mientras está activo “i”, puedes calcular
cuanto tiempo está activo multiplicando por el tiempo que tarde en terminar

𝑗 𝑅𝑖
𝐼𝑖 = ⌈ · 𝐶𝑗⌉
Si hay varias, la interferencia 𝑇𝑗 𝑅𝑖
sería la suma de todas las interferencias 𝐼𝑖 = ∑ ⌈ ⌉ · 𝐶𝑗
𝑇𝑗
máximas sobre “i”

No se permite la explotación económica ni la transformación de esta obra. Queda permitida la impresión en su totalidad.
CUIDAD CON LA OPERACIÓN ⌈𝒂/𝒃⌉ NO ES SOLO UNA DIVISIÓN NORMAL, LUEGO, EL
Test de planificabilidad
RESULTADO SI ES DECIMAL SE APROXIMA HACÍA ARRIBA. LA OPREACIÓN SE LLAMA TECHO

En un sistema de tiempo real con n tareas independientes, planificadas mediante un esquema

expulsivo de prioridades fijas, y para una asignación concreta de prioridades a las tareas, se
cumplirán todos los plazos de respuesta si, y sólo si,

Para todas las tareas del sistema: El tiempo de respuesta de la tarea es menor o igual a su
plazo máximo de ejecución. Donde este tiempo de respuesta es la suma del tiempo de
ejecución de la tarea + todas las interferencias que le puedan hacer tareas más prioritarias

∀𝑖, 1 ≤ 𝑖 ≤ 𝑛, 𝑅𝑖 ≤ 𝐷𝑖

Reservados todos los derechos.

𝑅𝑖
𝑅𝑖 = 𝐶𝑖 + ∑ ⌈ ⌉ · 𝐶𝑗
𝑇𝑗
Calculo del tiempo de respuesta
Ri es la solución mínima de la ecuación la cual no es continua ni lineal por lo que No se puede
resolver analíticamente

Cada vez que vence un periodo

de una tarea se incrementa en las
unidades de tiempo de computa
de esta tarea.

En el inicio como todas se ponen a la vez se suman todas:

𝟏 + 𝟏 + 𝟑 = 𝟓. Luego cada vez que por ejemplo t1
acaba como su C1 es = 1 sumas 1, si termina t3 como su C3
es = 3 se suma 3…

Tiempo de respuesta de la tarea de Menor

prioridad
Es el instante en el que la función se cruza con la función lineal (la linea azul)

Resolver ecuación tiempo de respuesta

Se puede resolver mediante esta relación de recurrencia

𝑤𝑖𝑛
𝑤𝑖𝑛+1 = 𝐶𝑖 + ∑ ⌈ ⌉ · 𝐶𝑗
𝑇𝑗

¿No te llega para pagar Wuolah Pro? ¿Un año sin anuncios gratis? ¡Clic aquí!
a64b0469ff35958ef4ab887a898bd50bdfbbe91a-7568767
 Como valor inicial se puede pillar

𝑤𝑖0 = 𝐶𝑖 + ∑ 𝐶𝑗

Fin del cálculo: El cálculo termina cuando se consiguen en 2 iteraciones seguidas el mismo
valor o cuando el tiempo de respuesta (lo que estamos calculando) es superior al tiempo
máximo de la tarea. En este caso no sabemos el tiempo de respuesta de la tarea pero
sabemos que NO es planificable

No se permite la explotación económica ni la transformación de esta obra. Queda permitida la impresión en su totalidad.
Ejemplo de cálculo de los tiempos de respuesta

Dadas estas tareas con estos

plazos y prioridades de
mayor a menor

Tiempo de respuesta Ri de T4 (R4)

Reservados todos los derechos.

Ya que es la menos prioritaria todas las demás le pueden
hacer interferencia. Si miramos en la gráfica de tiempo
tenemos que

𝜏4 𝑤0 = 4 + 3 + 2 + 3 = 12
12 12 12
𝑤1 = 4 + ⌈12⌉ · 3 + ⌈ 8 ⌉ · 2 + ⌈20⌉ · 3 = 14

14 14 14
𝑤2 = 4 + ⌈12⌉ · 3 + ⌈ 8 ⌉ · 2 + ⌈20⌉ · 3 = 17

17 17 17
𝑤3 = 3 + ⌈ ⌉ · 3 + ⌈ ⌉ · 2 + ⌈ ⌉ · 3 = 19
12 8 20

19 19 19
𝑤4 = 4 + ⌈12⌉ · 3 + ⌈ 8 ⌉ · 2 + ⌈20⌉ · 3 = 19

19 es el mismo en w3 y w4, además coincide con el valor

de la gráfica que coincide con la linea

Explicación para seres humanos

w0 es tiempo de ejecución de t4 + el t de ejecución de todas las que son más prioritarias. A
partir de ahí, w1 es el t de ejec de t4 + el tiempo de ejec de cada tarea por el valor anterior (12)
entre su tiempo de tarea, osea el sumatorio de todos los tiempos de interferencia de las otras
tareas sobre t4. La siguiente es igual, pero en vez de 12 es 14 entre los Ti de cada tarea…

Así hasta que hemos llegado a que en w3 y w4 el resultado es el mismo, por lo que fin,
sabiendo que 19 es el valor del tiempo de respuesta de T4. COMO 19 es menor que la deadline
de t4 (D4 = 22), está garantizado que t4 SIEMPRE cumplirá sus plazos en este sistema

La sincronización entre tareas

¿No te llega para pagar Wuolah Pro? ¿Un año sin anuncios gratis? ¡Clic aquí!
a64b0469ff35958ef4ab887a898bd50bdfbbe91a-7568767
 Una de las restricciones más importantes del test de planificabilidad anterior es la de suponer
que las tareas son independientes. Pero eso no siempre es así, en la mayoría de los sistemas
de interés práctico las tareas necesitarán comunicarse. Cuando esto pasa hace falta
sincronización. Para analizar esto asumiremos que solo hay exclusión mutua en las secciones
criticas y que se usan locks del tipo 𝑷(𝑺) 𝑝𝑎𝑟𝑎 𝑪𝒆𝒓𝒓𝒂𝒓 𝑦 𝑽(𝑺) 𝑝𝑎𝑟𝑎 𝒂𝒃𝒓𝒊𝒓.

Sin embargo, en sistemas de tiempo real esta solución no es válida, ya

que puede producir una situación denominada inversión de prioridades,
que invalida el test de planificabilidad

No se permite la explotación económica ni la transformación de esta obra. Queda permitida la impresión en su totalidad.
La inversión de prioridades
La inversión de prioridades ocurre cuando una tarea menos prioritaria se ejecuta por delante
de una más prioritaria. El tiempo total de bloqueo debido a una tarea menos prioritaria no
está acotado, al poder intervenir tareas de prioridad intermedia, por lo que pueden no
cumplirse los requisitos temporales que hemos medido en los test.

Reservados todos los derechos.

Protocolos de sincronización
La inversión de prioridades no puede evitarse. Los bloqueos comprometen la planificabilidad
del sistema. Por lo que se trata de conseguir que el bloqueo esté acotado, se produzca el
menor número de veces posible y que sea medible.

Los protocolos de sincronización de tiempo real evitan la inversión de prioridad no acotada

Protocolos más importantes: Herencia de prioridad y Techo de prioridad inmediato

(o protección por prioridad). Creo que solo damos este segundo.

Ambos hacen que la inversión de prioridad, o retraso que una tarea sufre a causa de tareas
de prioridad inferior sea función de la duración de una o varias secciones críticas y no sea
función de la duración de tareas completas

Protocolo del techo de prioridad inmediato

Consiste en que A cada semáforo le asociaremos un techo, equivalente a la mayor prioridad
de las tareas que lo pueden usar. Con este protocolo, una tarea que accede a un semáforo
hereda inmediatamente el techo de prioridad del semáforo. La sección crítica se ejecuta con la
prioridad del techo del semáforo que la guarda, la tarea aumenta su prioridad al entrar.

Propiedades
• Cada tarea se puede bloquear una vez como máximo, en cada ciclo. Además si una
tarea se bloquea, lo hace al principio del ciclo.

¿No te llega para pagar Wuolah Pro? ¿Un año sin anuncios gratis? ¡Clic aquí!
a64b0469ff35958ef4ab887a898bd50bdfbbe91a-7568767
 • No puede haber interbloqueos.

No se permite la explotación económica ni la transformación de esta obra. Queda permitida la impresión en su totalidad.
Prioridad 𝑡𝑒𝑐ℎ𝑜(𝑋) = 2 y Prioridad 𝑇𝑒𝑐ℎ𝑜(𝑌) = 1
esto ya que la tarea más alta que usa X es la 2 y la
más alta que usa Y es 1

Fijarse en cuando hacen p() y v() cual entra y eso

Cálculo de los factores de bloqueo máximos

Por las propiedades que da este protocolo hacen que tenga un comportamiento predecible
por lo que los costes y los tiempos en el sistema son predecibles.

Reservados todos los derechos.

Factor de bloqueo Bi: Tiempo máximo de retraso que sufre la tarea “i”. Para los el
protocolo de techo de prioridad inmediato, El Bi es la duración máxima de todas las secciones
críticas cuyo techo es ≥ 𝑝𝑟𝑖𝑜𝑟𝑖𝑑𝑎𝑑 𝑑𝑒 𝑙𝑎 𝑡𝑎𝑟𝑒𝑎 𝑖, que son utilizadas por tareas de prioridad
inferior

• Para la tarea de prioridad más baja 𝑩𝒏 = 𝟎, ya que no puede ser bloqueada por tareas
de prioridad inferior.
• Para el resto de tareas es está ecuación:

𝐵𝑖 = max{𝑘, 𝑠|𝑘 ∈ 𝑙𝑝(𝑖) ^ 𝑠 ∈ 𝑢𝑠𝑎(𝑘) ^ 𝑡𝑒𝑐ℎ𝑜(𝑠) ≥ 𝑝𝑟𝑖𝑜𝑟𝑖𝑑𝑎𝑑(𝑖)} 𝐶𝑘,𝑠

Explicación: Se consideran las tareas “k” de prioridad inferior a “i”, y entonces se miran los
semáforos “s” que pueden cerrar, y se selecciona aquellos cuyo techo tenga “𝑝𝑟𝑖𝑜𝑟𝑖𝑑𝑎𝑑 ≥ 𝑖",
por último, se miran los tiempos de cómputo de las secciones que guardan esos semáforos
“𝐶𝑘, 𝑠" y se selecciona la de mayor duración.

Incorporación del factor de bloqueo al test

Antes, para calcular el tiempo de respuesta en el peor caso, había que sumar el tiempo que le
constaba a la tarea “i” + el tiempo que era bloqueada por cada tarea con mayor prioridad
que ella. Pues ahora además hay que sumarle “Bi”, el tiempo que la pueden bloquear las
tareas con menor prioridad que ella.

𝑅𝑖
𝑅𝑖 = 𝐶𝑖 + 𝑩𝒊 + ∑ ⌈ ⌉ · 𝐶𝑗
𝑇𝑗

Seguidme en wuolah “TurboApuntesPat” hay apuntes de todas las

asignaturas, no te arrepentirás juju
Sígueme en twitter @MaikPatataOtaku ;)
Y en Instagram también juju @potatproductions :p

a64b0469ff35958ef4ab887a898bd50bdfbbe91a-7568767