patologías de la programación concurrente


Hoy hemos visto en el tema cuatro del módulo uno de la asignatura programación concurrente del máster en computación e la Universidad de Cantabria las razones por las que una aplicación realizada como una serie de procesos concurrentes independientes, que cooperan o compiten entre sí puede fallar y cómo se manifiesta ese fallo. También hemos visto los mecanismos que aseguran que esos fallos no puedan producirse.

Los problemas que se pueden presentar en un aplicación concurrente se clasifican en problemas de vivacidad (i.e liveness) y problemas de seguridad. (i.e safety)

Los primeros consisten en la incapacidad de la aplicación concurrente de producir resultados, de avanzar hacia los objetivos de la aplicación debido a bloqueos activos (i.e livelock) (en donde se ejecutan sentencias que no hacen nada útil) o un aplazamiento indefinido en la ejecución de sus sentencias porque nunca termina de obtener procesador para ejecutarlas (i.e starvation) o esperas indefinidas a la obtención de recursos con ciclos de apropiación mutuos (i.e deadlock)

Los segundos consisten en la ejecución errónea de sentencias con dependencias funcionales o de datos en flagrante incumplimiento de esas dependencias conduciendo a errores en el resultado del programa o esperas a eventos que nunca se van a producir, entrada simultánea en secciones críticas que no deben ser interrumpidas, no respetar los puntos de sincronismo, etc.

Los dos problemas son contrapuestos en el sentido que evitar uno de ellos mediante el uso de técnicas apropiadas de programación concurrente puede provocar que el otro aparezca. Normalmente la ingeniería de software pone énfasis en la seguridad, es decir, evitar que la aplicación realice operaciones incorrectas u obtenga resultados incorrectos. El mayor tiempo de diseño se dedica a evitar problemas de vivacidad, evitando bloqueos y mejorando el rendimiento de la aplicación.

Las técnicas de programación concurrente buscan aumentar la seguridad haciendo que no se producen carreras críticas sobre recursos y que los objetos compartidos son accedidos cuando tienen un estado coherente. Esta coherencia se basa en especificar invariantes (condiciones sobre el estado del objeto) que se deben cumplir antes de acceder al objeto y tras abandonarlo. Otra cuestión de seguridad son los conflictos en las escrituras y lecturas:

  • un thread no puede escribir un nuevo valor en un atributo, mientras otro thread lo está leyendo (conflicto lectura/escritura);
  • dos threads concurrentes no pueden escribir un mismo atributo (conflicto de escritura/escritura)

Para evitar los bloqueos se utilizan gestores que arbitran el acceso a los objetos compartidos, detecta los bloqueos y ejecuta soluciones a los mismos. También se puede hacer programas libres de bloqueos por diseño mediante técnicas anticipadoras como la política del banquero o evitando las estructuras de recursos que conducen a bloqueos mediante técnicas formales basadas en modelos de grafos.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s