Diseño de sistemas concurrentes Manuel Carro Universidad Politécnica de Madrid Necesidad de diseño Hasta ahora, problemas ya cerrados: 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... 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 M. Carro (UPM) Diseño 2 / 19 Operaciones externas Frecuentemente con características especiales / restricciones de uso (No) Bloqueantes: suspenden (o no) el proceso llamante hasta que se cumple una condición Ej., lectura de un teclado, un sensor (No) Reentrantes: preparadas para ser llamadas (o no) concurrentemente Pueden necesitar protección Un ejemplo: escalera mecánica Arrancar/parar escalera con sensor presencia personas Presencia: arrancar durante T segundos (suficiente para que llegue al final) Parar después si no hay nadie en la escalera sólo guiándonos por T Interfaz con el exterior: procedure Sensor ; Detecta paso de personas procedure Arrancar Esc ; Pone en marcha e s c a l e r a procedure Detener Esc ; Detiene escalera M. Carro (UPM) Diseño 3 / 19 M. Carro (UPM) Diseño 4 / 19
Escalera mecánica (Cont.) Para manejar tiempo: procedure Hora (D : out T Tiempo ) ; Tiempo desde pasado procedure Espera ( T : in T Tiempo ) ; Suspende proceso Sensor es bloqueante Espera(T) es bloqueante Arrancar Esc y Detener Esc no son reentrantes, ni pueden ser llamadas simultáneamente; pueden tardar cierto tiempo No se debe llamar a Arrancar Esc cuando ya está en movimiento (sim. con Detener Esc) A diseñar! Diseño: directrices y pistas Clases de procesos y recursos: Algoritmos de control (normalmente un bucle) Procesos Bucles simples (caso anterior simplificado) Recursos 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) M. Carro (UPM) Diseño 5 / 19 M. Carro (UPM) Diseño 6 / 19 Operaciones bloqueantes Detienen un proceso de forma no interrumpible Normalmente procesos separados para operaciones bloqueantes Datos recogidos disponibles mediante recurso compartido Posible excepción: cadencia clara de uso Ejemplo particular: temporizadores Usualmente un proceso temporizador por cada temporización Avisa final temporización mediante acceso compartido. Operaciones simultáneas Un proceso tiene que realizar varias cosas simultáneamente? Nos hemos equivocado: necesitamos más procesos e interacciones M. Carro (UPM) Diseño 7 / 19 M. Carro (UPM) Diseño 8 / 19
Operaciones no reentrantes Si hay operaciones externas que no permiten acceso reentrante: Poner todos los accesos en el mismo proceso El método más sencillo: secuencializa Pero no permitiría concurrencia entre ellos Realizar accesos desde POST de op. recurso (acabaría dentro de un objeto protegido / sevidor de paso de mensajes) Pero bloquea acceso al recurso durante ejecución Accediendo desde distintos procesos y/o recursos Cuidar sincronización (evitar accesos indeseados) Legítimo, pero más frágil y difícil de verificar Consultas al estado del recurso Generalmente inseguras: sirven para monitorizar, fallan para tomar decisiones desde fuera recurso Protección expĺıcita recurso: Reduce concurrencia Encapsular zona protegida como operación única? Parte del proceso pasa a recurso recurso poco general Sincronización cuidada: delicada M. Carro (UPM) Diseño 9 / 19 M. Carro (UPM) Diseño 10 / 19 Vivacidad No se suele tratar a este nivel Depende de técnica de implementación Pero el diseño debe permitir correcta vivacidad Operaciones del recurso Dependen de lo que los procesos necesiten Diseño exacto: postergado hasta saber qué misión tiene cada recurso y proceso Si sólo dotamos de concurrencia a un TAD secuencial: Operaciones normalmente definidas Pero cuidado con operaciones consultoras M. Carro (UPM) Diseño 11 / 19 M. Carro (UPM) Diseño 12 / 19
Recursos dependiente del núm. procesos Algunos procesos sólo tienen una ocurrencia Algunos procesos tendrán varias instancias 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áquina expendedora 16 productos (0 al 15 T Prod); saldo inicial 0 Tras introducir moneda: hay cambio actualiza y visualiza el saldo; si no, devuelve moneda Al pulsar devolución: devolver saldo y dejarlo a 0 Al seleccionar producto: 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 13 / 19 M. Carro (UPM) Diseño 14 / 19 Máquina expendedora: interfaz procedure Maq. Detectar Moneda ( Valor : 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 return Boolean ; Maq. HayCambio <=> se puede devolver dinero procedure Maq. Detectar Devolucion ; Bloquea hasta que se pulsa e l botón de devoluci ón procedure Maq. Devolver ( Cantidad : in I n t e g e r ) ; Devuelve a l c l i e n t e l a cantidad e s p e c i f i c a d a f u n c t i n Maq. Precio ( Producto : T Prod ) return I n t e g e r ; Devuelve e l p r e c i o de un producto procedure Maq. Detectar Seleccion ( Producto : out T Prod ) ; Bloquea hasta producto seleccionado ; l o devuelve procedure Maq. S e r v i r ( Producto : in T Prod ) ; Sirve una unidad del producto procedure Maq. Mostrar ( Cantidad : in I n t e g e r ) ; Muestra una cantidad en e l d i s p l a y Editor interactivo 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 15 / 19 M. Carro (UPM) Diseño 16 / 19
Abstracciones para el editor function Leer Comando return T Comando ; Lee comando del e x t e r i o r procedure Ejecutar Comando (Cmd : in T Comando ; Doc : in out T Doc ) ; Modifica e l documento Doc de acuerdo con e l comando Cmd. procedure E x t r a e P a n t a l l a ( Doc : in T Doc ; Vis : out T Doc ) ; Copia l a parte v i s i b l e del documento. procedure M o s t r a r P a n t a l l a ( Pant : in T Doc ) ; Muestra documento en p a n t a l l a Sistema de supervisión y registro Cada UAD explora una entrada externa, con pausa entre exploraciones Si valor leído excede ĺımite, envía mensaje a UCR Periódicamente, UCR pide a UADs la última medida 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 UAD1 UAD2 UADn Unidad Central de Registro M. Carro (UPM) Diseño 17 / 19 M. Carro (UPM) Diseño 18 / 19 Sistema de supervisión y registro (Cont.) Cuestiones (casi) abiertas: Interfaz (razonable) con sensores y disco Implementación de la pausa entre lecturas Decidir: Número procesos, recursos, código procesos Especificación recurso Probar: Desacoplamiento cadencias UCR/UADs No interbloqueo peticiones No retraso (si posible) por acceso a disco M. Carro (UPM) Diseño 19 / 19