1
Conceptos de Concurrencia
Un thread de control =? programación secuencial, monoprocesador.
Múltiples threads de control? procesos? concurrencia.
Los procesos se comunican y sincronizan, en base a dos criterios:
Exclusión mútua en el acceso a secciones críticas de código o datos.
Espera por condición.
La historia de la concurrencia=?
En los 60’s =? Evolución de los sistemas operativos. Controladores de dispositivos independientes(canales). Multiprogramación.
En los 70´s ? Necesidad de formalizar la concurrencia en los lenguajes.
En los 80’s? Redes, procesamiento distribuido.
En los 90’s =? MPP , InterNet, CS, Web computing…
2
Concurrencia: Clases de Aplicaciones
El primer tipo de aplicaciones se corresponde cuando ejecutamos N procesos independientes sobre M procesadores, con N > M. Un sistema de software de “multithreading” maneja simultáneamente tareas independientes, asignando (por ejemplo por tiempos) los procesadores de que dispone.
Ejemplos típicos:
Sistemas de ventanas en PCs o WS.
Time sharing en sistemas operativos multiprocesador.
Sistemas de tiempo real en plantas industriales.
3
Concurrencia: Clases de Aplicaciones
El segundo tipo de aplicaciones es el cómputo distribuido: una red de comunicaciones vincula procesadores diferentes sobre los que se ejecutan procesos que se comunican esencialmente por mensajes. Cada componente del sistema distribuido puede hacer a su vez multithreading.
Ejemplos típicos:
Servidores de archivos (recursos) en una red.
Sistemas de Bases de datos distribuidas (bancos, reservas de vuelos).
Servidores WEB distribuidos.
Arquitecturas cliente–servidor.
Sistemas tolerantes a fallas.
4
Concurrencia: Clases de Aplicaciones
El procesamiento paralelo es el tercer tipo de aplicaciones. Se trata de resolver un dado problema en el menor tiempo posible, utilizando una arquitectura multiprocesador en la que se pueda distribuir la tarea global en tareas (independientes? interdependientes?) que puedan ejecutarse en diferentes procesadores.
Paralelismo de datos y paralelismo de procesos.
Ejemplos típicos:
Cálculo científico. Modelos de sistemas (meteorología, movimiento planetario).
Gráficos, procesamiento de imágenes, realidad virtual, procesamiento de video.
Problemas combinatorios y de optimización lineal y no lineal. Modelos econométricos.
5
Paradigmas de resolución de programas concurrentes
Si bien el número de aplicaciones es muy grande, en general los “patrones” de resolución concurrente son pocos:
1-Paralelismo iterativo, 2-paralelismo recursivo, 3-productores y consumidores, 4-clientes y servidores, 5-pares que interactúan.
En el paralelismo iterativo un programa tiene un conjunto de procesos (posiblemente idénticos) cada uno de los cuáles tiene uno o más loops. Es decir cada proceso es un programa iterativo.
La idea es que si estos procesos cooperan para resolver un único problema (ejemplo un sistema de ecuaciones) pueden trabajar independientemente y sincronizar por memoria compartida o envío de mensajes.
6
Paradigmas de resolución de programas concurrentes
En el paralelismo recursivo el problema general (programa) puede descomponerse en procesos recursivos que trabajan sobre partes del conjunto total de datos.
Ejemplos clásicos son por ejemplo el sorting by merging o el cálculo de raíces en funciones continuas.
Los esquema productor-consumidor muestran procesos que se comunican. Es habitual que estos procesos se organicen en pipes a través de los cuáles fluye la información. Cada proceso en el pipe es un filtro que consume la salida de su proceso predecesor y produce una salida para el proceso siguiente.
7
Paradigmas de resolución de programas concurrentes
Cliente-servidor es el esquema dominante en las aplicaciones de procesamiento distribuido. Los servidores son procesos que esperan pedidos de servicios de múltiples clientes. Naturalmente unos y otros pueden ejecutarse en procesadores diferentes. Los mecanismos de invocación son variados (rendezvous y RPC por ejemplo). El soporte distribuido puede ser muy simple (LAN) o extendido a toda la WEB.
En los esquemas de pares que interactúan los procesos (que forman parte de un programa distribuido) resuelven partes del problema (normalmente mediante código idéntico) e intercambian mensajes para avanzar en la tarea. El esquema permite mayor grado de asincronismo que C-S.
8
Programa Concurrente
Un programa concurrente especifica dos o más programas secuenciales que pueden ejecutarse concurrentemente en el tiempo como tareas o procesos.
Un proceso o tarea es un elemento concurrente abstracto que puede ejecutarse simultáneamente con otros procesos o tareas, si el hardware lo permite. (recordar los TASKs de ADA).
Un programa concurrente puede tener N procesos habilitados para ejecutarse concurrentemente y un sistema concurrente puede disponer de M procesadores cada uno de los cuales puede ejecutar uno o más procesos.
9
Objetivos de los sistemas concurrentes
Ajustar el modelo de arquitectura de hardware y software al problema del mundo real a resolver.
Incrementar la perfomance, mejorando los tiempos de respuesta de los sistemas de procesamiento de datos, a través de un enfoque diferente de la arquitectura física y lógica de las soluciones.
Algunas ventajas que merecen comentarse son la velocidad de ejecución que se puede alcanzar, la mejor utilización de la CPU de cada procesador, y la explotación de la concurrencia inherente a la mayoría de los problemas reales.
10
Areas de estudio en Programación Concurrente
ELECCION DE LA GRANULARIDAD :
Significa optimizar (para una dada aplicación) la relación entre el número de procesadores y el tamaño de la memoria total.
MANEJO DE LOS RECURSOS:
Asignación de recursos compartidos, métodos de acceso a los recursos, bloqueo y liberación de recursos, seguridad y consistencia de los recursos.
SINCRONIZACIÓN:
Se debe asegurar el orden correcto (incluyendo el tiempo) de las acciones que los procesos ejecutan. Este orden es dinámico e interdependiente. El objetivo de la sincronización es restringir las “historias”o “threads” de un programa concurrente sólo a las permitidas.
11
Sincronización en Programación Concurrente
Sincronización por exclusión mútua
Significa asegurar que sólo un proceso tenga acceso a un recurso compartido en un instante de tiempo.
Si el programa tiene “secciones críticas” que pueden compartir más de un proceso, la exclusión mútua evita que dos o más procesos puedan encontrarse en la misma sección crítica al mismo tiempo.
Sincronización por condición:
Debe permitir bloquear la ejecución de un proceso hasta que se cumpla una condición dada.
Ejemplos de los dos mecanismos de sincronización en un problema de utilización de un área de memoria compartida (buffer limitado con productores y consumidores).
12
Comunicación y Prioridad en Programación Concurrente
La comunicación entre procesos concurrentes indica el modo en que se organiza y trasmiten datos entre tareas concurrentes.
Esta organización requiere especificar protocolos para controlar el progreso y corrección de la comunicación.
Los protocolos deben contemplar la posibilidad de pérdida de información.
Un proceso que tiene mayor prioridad puede causar la suspensión (pre-emption) de otro proceso concurrente. Análogamente puede tomar un recurso compartido, obligando a retirarse a otro proceso que lo tenga en un instante dado.
13
Conceptos relacionados con la Programación Concurrente
Dos o más procesos pueden entrar en deadlock, si por un error en la programación concurrente ambos se quedan esperando que el otro libere un recurso compartido.La ausencia de deadlock es una propiedad necesaria en los procesos concurrentes.
Una propiedad deseable en los sistemas concurrentes es el equilibrio en el acceso a los recursos compartidos por todos los procesos (fairness).
Dos situaciones NO deseadas en los programas concurrentes son la inanición de un proceso (no logra acceser a los recursos compartidos) y el overloading de un proceso (la carga asignada excede su capacidad de procesamiento).
14
Desventajas de la Programación Concurrente
En Programación Concurrente los procesos no son completamente independientes y comparten recursos. La necesidad de utilizar mecanismos de exclusión mútua y sincronización agrega complejidad a los programas ===> menor confiabilidad.
Los procesos iniciados dentro de un programa concurrente pueden NO estar “vivos”. Esta pérdida de la propiedad de liveness puede indicar deadlocks o una mala distribución de recursos.
La comunicación y sincronización produce un overhead de tiempo, inútil para el procesamiento. Esto en muchos casos desvirtúa la mejora de perfomance buscada.
Hay un no determinismo implícito en el interleaving de los procesos concurrentes. Esto significa que dos ejecuciones del mismo programa no necesariamente son idénticas ===> dificultad para la interpretación y debug.
15
Problemas asociados con Progr. Concurrente
La mayor complejidad en la especificación de los procesos concurrentes significa que los lenguajes de programación tienen requerimientos adicionales. ===> mayor complejidad en los compiladores y sistemas operativos asociados.
Aumenta el tiempo de desarrollo y puesta a punto respecto de los programas secuenciales. También puede aumentar el costo de los errores ===> mayor costo de los ambientes y herramientas de Ingeniería de Software de sistemas concurrentes.
Para obtener una real mejora de perfomance, se requiere adaptar el software concurrente al hardware paralelo.
La paralelización de algoritmos secuenciales NO es un proceso directo, que resulte fácil de automatizar.
16
Mecanismos de comunicación y sincronización entre procesos.
Memoria compartida:
Los procesos intercambian mensajes sobre la memoria compartida o actúan coordinadamente sobre datos residentes en ella. Lógicamente los procesos no pueden operar simultáneamente sobre la memoria compartida, lo que obligará a BLOQUEAR y LIBERAR el acceso a la memoria.
La solución más elemental será una variable de control tipo “semáforo” que habilite o no el acceso de un proceso a la memoria compartida.
Pasaje de Mensajes:
Es necesario establecer un “canal” (lógico o físico) para trasmitir información entre procesos. También el lenguaje debe proveer un protocolo adecuado.
Para que la comunicación sea efectiva los procesos deben “saber” cuando tienen mensajes para leer y cuando deben trasmitir mensajes.
Página siguiente  |