Programación Concurrente: Dependencia de estado parte #1
Dejemos dos términos en la mensa.
Condiciones para realizar cualquier acción
- Externas: Un objeto recibe un mensaje que solicita la realización de una acción.
- Internas: El objeto se encuentra en el estado adecuado para realizar la acción.
Casi todos los problemas de diseño relativos a clases que poseen acciones dependientes de estado dependen de las consideraciones necesarias para completar un diseño tal que tenga en cuenta todas las posibles combinación de mensaje y estados.
Ejemplo
Suponga que le piden que tome una nota de un mensaje telefonico.
tengo telefono no tengo telefono
Suena el teléfono responder al teléfono responder al telefono
tomar mensaje escribir mensaje ?
Dug dice que el sistema idea seria el que no tiene pre condiciones que las clases y los métodos desarrollados simplemente siempre satisfaces las postcondiciones, es decir creando clases y métodos que no validen sus pre-condiciones y simplemente que hagan las postcondiciones sean validas.
Enfoques:
Se identifican dos enfoques que surgen de unas perspectivas de diseño en las que priman entre si la actividad y la seguridad:
- Optimista: los métodos de tipo probar y ver, permiten probar cuando se invocan pero no siempre tiene éxito por lo tanto pueden tener que enfrentarse a fallos.
- Conservador: los métodos de comprobar y actuar, se niegan a seguir adelante salvo que sean validas las precondiciones. Cuando las precondiciones son validas las acciones siempre tienen éxito.
En sistemas concurrentes no se recomienda usar métodos que no comprueban sus precondiciones ya que hasta en el mejor de los casos el resultado es problemático.
Se pueden usar los dos en combinacion, optimista y conservador.
Los enfoques Optimistas se deben usar cuando:
- No se pueden comprobar las precondiciones y restricciones relacionadas.
- Cuando al respuesta depende de otros sistema fuera del nuestro.(Ejemplo petición a servidor).
- Cuando las condiciones cambias por que las acciones de otro hilo provocaron el cambio.
Excepciones
Las excepciones son importante en un algoritmo concurrente ya que las vamos a necesitar cuando se aplique un enfoque Optimista.
Posibles respuestas a una falla:
- Finalizacion súbita
- Continuación
- Vuelta a tras
- Avance
- Nuevo intento
- Delegación a manos de los manejadores
Fianlizacion subita
La acción, método, algoritmo o proceso muera inmediatamente normalmente a través de un excepción.
Debe pasar solo:
- Cuando se esta seguro de que el fallo local impone un fallo a toda la actividad completa y que los objetos implicados de la actividad no volverán a ser ejecutados nunca.
- Cuando no es posible resolver un fallo que normalmente seria recuperable.
- Cuando los objetos se comparten intrínsecamente entre actividades t no existe una forma de volver a establecer unos estado coherentes de los objetos tras producirse un fallo y no existe ninguna forma o practica de salir de una operación que esta fallando.
Continuación
Debe pasar:
- Una invocación fallida no posee efectos ni es el estado del objeto que se hace la llamada, ni tampoco sobre los requisitos globales de funcionalidad de la actividad en curso.
- Solo en eventos y en protocolos de mensajes unidimensionales.
Vuelta a tras
Se hace para que si ocurre un fallo el objeto quede en el mismo estado que tuviera antes de intentar realizar la operación.
Estilos, existen dos etilos para implementar esta respuesta:
- Acción provisional: Entonces antes de intentar realizar una acción, se construye una nueva representación que en caso de tener éxito pasara a sustituir al estado actual. De este modo no es preciso deshacer nada si se produce un fallo. Suelen usarse cuando las acciones no estan complemente sincronizadas, eliminana la posibilidad de que otros hilos puedan ver unas representaciones incoherentes(que otros hilos usen o vean un objeto que tenga errores) y es mucho mas eficiente cuando las lecturas son mucho mas frecuentes que las escrituras.
- Punto de comprobación: Entonces antes de realizas una acción, se registra el estado actual del objeto en una variable historia, quizá en una forma de Memento. El objeto procede a realizar la acción y si ocurre un fallo es posible devolver a los campos sus valores anteriores. Todo mensaje que se envían dentro de este metodo deben tener un mensaje inverso. Ejemplo: Toda operación de credito se puedria deshacer mediante otra de debito.
Referencias
- Programación concurrente en java y principios de patrones de diseño - Segunda edición -Dug Lea