Diseño de sistemas concurrentes

Necesidad de diseño
Hasta ahora, problemas ya cerrados:
I
I
Diseño de sistemas concurrentes
I
Número de procesos, recursos
Código de procesos
Especificación de recursos
¿De dónde salen?
Método general difı́cil de elaborar, pero. . .
Manuel Carro
I
Universidad Politécnica de Madrid
I
Algunos consejos y directrices
Experiencia
¡Asegurar corrección, funcionalidad!
Este texto se distribuye bajo los términos de la Creative Commons License
M. Carro (UPM)
Diseño
1 / 19
Operaciones externas
2 / 19
Arrancar/parar escalera con sensor presencia personas
(No) Bloqueantes: suspenden (o no) el proceso llamante hasta que
se cumple una condición
Ej., lectura de un teclado, un sensor
Parar después si no hay nadie en la escalera — sólo guiándonos por T
procedure Sensor ; −− Detecta paso de personas
procedure A r r a n c a r E s c ; −− Pone en marcha e s c a l e r a
procedure Detener Esc ; −− Detiene e s c a l e r a
Pueden necesitar protección
Diseño
Presencia: arrancar durante T segundos (suficiente para que llegue al
final)
Interfaz con el exterior:
(No) Reentrantes: preparadas para ser llamadas (o no)
concurrentemente
M. Carro (UPM)
Diseño
Un ejemplo: escalera mecánica
Frecuentemente con caracterı́sticas especiales / restricciones de uso
I
M. Carro (UPM)
3 / 19
M. Carro (UPM)
Diseño
4 / 19
Diseño: directrices y pistas
Escalera mecánica (Cont.)
Clases de procesos y recursos:
Para manejar tiempo:
procedure Hora (D : out T Tiempo ) ; −− Tiempo desde pasado
procedure Espera ( T : i n T Tiempo ) ; −− Suspende proceso
Sensor es bloqueante
Procesos
Recursos
Espera(T) es bloqueante
Arrancar Esc y Detener Esc no son reentrantes, ni pueden ser llamadas
simultáneamente; pueden tardar cierto tiempo

 Algoritmos de control (normalmente un bucle)
Bucles simples (caso anterior simplificado)

Accesos
bloqueantes

 Sincronización pura
Acceso concurrente a estructuras de datos

Mezcla de ambos
Procesos y recursos: diseño interdependiente
A menudo, varias soluciones (con variación de responsabilidades)
No se debe llamar a Arrancar Esc cuando ya está en movimiento
(sim. con Detener Esc)
¡A diseñar!
M. Carro (UPM)
Diseño
5 / 19
Operaciones bloqueantes
M. Carro (UPM)
Diseño
6 / 19
Operaciones simultáneas
Detienen un proceso de forma no interrumpible
¿Un proceso tiene que realizar varias cosas simultáneamente?
Normalmente procesos separados para operaciones bloqueantes
Nos hemos equivocado: necesitamos más procesos e interacciones
Datos recogidos disponibles mediante recurso compartido
Posible excepción: cadencia clara de uso
Ejemplo particular: temporizadores
I
I
Usualmente un proceso temporizador por cada temporización
Avisa final temporización mediante acceso compartido.
M. Carro (UPM)
Diseño
7 / 19
M. Carro (UPM)
Diseño
8 / 19
Operaciones no reentrantes
Consultas al estado del recurso
Generalmente inseguras: sirven para monitorizar, fallan para tomar
decisiones desde fuera recurso
Protección explı́cita recurso:
Si hay operaciones externas que no permiten acceso reentrante:
Poner todos los accesos en el mismo proceso
I
I
El método más sencillo: secuencializa
Pero no permitirı́a concurrencia entre ellos
I
I
Realizar accesos desde POST de op. recurso (acabarı́a dentro de un
objeto protegido / sevidor de paso de mensajes)
I
Pero bloquea acceso al recurso durante ejecución
I
Reduce concurrencia
¿Encapsular zona protegida como operación única?
Parte del proceso pasa a recurso → recurso poco general
Sincronización cuidada: delicada
Accediendo desde distintos procesos y/o recursos
I
I
Cuidar sincronización (evitar accesos indeseados)
Legı́timo, pero más frágil y difı́cil de verificar
M. Carro (UPM)
Diseño
9 / 19
Vivacidad
M. Carro (UPM)
Diseño
10 / 19
Operaciones del recurso
No se suele tratar a este nivel
Dependen de lo que los procesos necesiten
Depende de técnica de implementación
Diseño exacto: postergado hasta saber qué misión tiene cada recurso
y proceso
Si sólo dotamos de concurrencia a un TAD secuencial:
Pero el diseño debe permitir correcta vivacidad
I
I
M. Carro (UPM)
Diseño
11 / 19
Operaciones normalmente definidas
Pero cuidado con operaciones consultoras
M. Carro (UPM)
Diseño
12 / 19
Recursos dependiente del núm. procesos
Máquina expendedora
Algunos procesos sólo tienen una ocurrencia
16 productos (0 al 15 — T Prod); saldo inicial 0
Algunos procesos tendrán varias instancias
Tras introducir moneda: hay cambio → actualiza y visualiza el saldo;
si no, devuelve moneda
Otros tienen 1 instancia en un caso particular, k en general (sin
pervertir el problema)
A menudo considerar k (aunque sólo se implemente para k = 1) lleva
a soluciones más elegantes
Y, por supuesto, más escalables
M. Carro (UPM)
Diseño
13 / 19
Saldo suficiente → servir producto, devolver la cantidad restante
(saldo a 0)
Saldo insuficiente → informar de la cantidad que falta, olvidar
selección
M. Carro (UPM)
Diseño
14 / 19
Editor interactivo
procedure Maq . Detectar Moneda ( V a l o r : out I n t e g e r ) ;
−− Bloquea hasta i n t r o d u c c i o n moneda ( de v a l o r v )
function Maq . Hay Cambio r e t u r n Boolean ;
−− Maq . HayCambio <=> se puede d e v o l v e r d i n e r o
procedure Maq . D e t e c t a r D e v o l u c i o n ;
−− Bloquea hasta que se p u l s a e l bot ón de d e v o l u c i ó n
procedure Maq . Devolver ( Cantidad : i n I n t e g e r ) ;
−− Devuelve a l c l i e n t e l a c a n t i d a d e s p e c i f i c a d a
f u n c t i n Maq . P r e c i o ( Producto : T Prod ) r e t u r n I n t e g e r ;
−− Devuelve e l p r e c i o de un p r o d u c t o
procedure Maq . D e t e c t a r S e l e c c i o n ( Producto : out T Prod ) ;
−− Bloquea hasta p r o d u c t o s e l e c c i o n a d o ; l o devuelve
procedure Maq . S e r v i r ( Producto : i n T Prod ) ;
−− S i r v e una unidad d e l p r o d u c t o
procedure Maq . M o s t r a r ( Cantidad : i n I n t e g e r ) ;
−− Muestra una c a n t i d a d en e l d i s p l a y
Diseño
I
I
Máquina expendedora: interfaz
M. Carro (UPM)
Al pulsar devolución: devolver saldo y dejarlo a 0
Al seleccionar producto:
15 / 19
Documento en edición en memoria
Acepta contı́nuamente pulsaciones (ordenes) usuario y las ejecuta
completamente (aunque tarden tiempo)
Refresca pantalla cuando no hay ordenes a procesar, pero sigue
aceptando órdenes durante el refresco
No refresca si no es necesario
M. Carro (UPM)
Diseño
16 / 19
Abstracciones para el editor
Sistema de supervisión y registro
Cada UAD explora una entrada externa, con pausa entre exploraciones
function Leer Comando r e t u r n T Comando ;
−− Lee comando d e l e x t e r i o r
Si valor leı́do excede lı́mite, envı́a mensaje a UCR
Periódicamente, UCR pide a UADs la última medida
procedure Ejecutar Comando (Cmd : i n
T Comando ;
Doc : i n out T Doc ) ;
−− M o d i f i c a e l documento Doc de acuerdo con
−− e l comando Cmd.
Cadencia de exploración más alta que la de peticiones de la UCR
Todas las mediciones se almacenan en disco (lento), asociadas a la
UAD
procedure E x t r a e P a n t a l l a ( Doc : i n T Doc ;
V i s : out T Doc ) ;
−− Copia l a p a r t e v i s i b l e d e l documento .
UAD1
UAD2
UADn
Unidad Central de Registro
procedure M o s t r a r P a n t a l l a ( Pant : i n T Doc ) ;
−− Muestra documento en p a n t a l l a
M. Carro (UPM)
Diseño
17 / 19
Sistema de supervisión y registro (Cont.)
Cuestiones (casi) abiertas:
I
I
Interfaz (razonable) con sensores y disco
Implementación de la pausa entre lecturas
Decidir:
I
I
Número procesos, recursos, código procesos
Especificación recurso
Probar:
I
I
I
Desacoplamiento cadencias UCR/UADs
No interbloqueo peticiones
No retraso (si posible) por acceso a disco
M. Carro (UPM)
Diseño
19 / 19
M. Carro (UPM)
Diseño
18 / 19