CSI Consultores

 
  • Aumentar fuente
  • Fuente predeterminada
  • Disminuir fuente
Home Etiqueta: Locks

Etiqueta: Locks

05.09.2009 06:27:46
admin

SyntaxHighlighter Build Test Page

Por: Guido J. Granobles.

En el post anterior vimos cuales eran los posibles escenarios en donde habría altas posibilidades de que ocurriese un DeadLock o más bien son escenarios donde inevitablemente sucederá un DeadLock tarde o temprano. Mencione entonces que para solucionar este potencial problema podemos omitir el uso de la palabra clave Synchronized y a cambio usar un objeto Lock por cada clase  con el cual podemos verificar si se ha podido o no asegurar el objeto que esta instanciando dicha clase.  Lock es en realidad una interface y es implementada por la clase ReentrantLock, esta clase implementa el método tryLock el cual intenta asegurar el objeto donde se ha instanciado ReentrantLock, el método devuelve true si el objeto se ha asegurado exitosamente o devuelve false en caso contrario,  El método tryLock no se quedara esperando si no puede asegurar el objeto y esta es su mayor ventaja con respecto a la palabra clave Synchronized ya que permite que el programa fluya por otra rama de código.

En el ejemplo que vimos en el  post anterior donde se intenta hacer transferencia de dinero entre dos cajas, debemos notar que este es un proceso Atómico con 2 transacciones un debito en una caja y un crédito en la otra donde ambas transacciones o ninguna debe llevarse a cabo. Por lo tanto un hilo debería poder asegurar ambos objetos (las 2 cajas) antes de empezar las operaciones.  Para ello la clase Caja tendrá un miembro lock que será una instancia de la clase ReentrantLock (línea 10 del listado de codigo abajo), el método transfer (línea 37) de la clase operaCaja hace uso de lock para asegurar el objeto Caja (líneas 48 y 51), si logra asegurar ambas cajas tanto origen como destino (línea 63), entonces procede a debitar y acreditar saldos en caso contrario sale del método retornando  un false. El hilo al verificar que no se llevo a cabo la transacción suspenderá su ejecución con un Sleep por 100 milésimas de segundo (líneas 106 y 126) y luego intenta de nuevo la transacción, este proceso se repite hasta que la transacción sea exitosa.  Pero bueno bien sabido es que un buen trozo de código vale más que mil palabras, veamos el ejemplo:

  hilos | Locks | DeadLocks | concurrencia
Comentarios 0Visitas: 1390  

02.09.2009 08:59:00
admin

Por Guido J. Granobles.

Es conocido por muchos que  el uso de la palabra clave synchronized ya sea para el establecimiento de métodos o bloques de código sincronizado afecta el desempeño óptimo de las aplicaciones en cuanto a velocidad de procesamiento se refiere.  Aunque el uso abusivo de este tipo de bloques de código se ha condenado desde sus inicios cabe decir que las constantes mejoras de la JVM a través de los años hace que la comparación entre el porcentaje de desempeño afectado VS los grandes beneficios  a la hora de resolver problemas de concurrencia, inclinan la balanza hacia este ultimo.  El principal problema asociado con el uso excesivo de los bloques de código sincronizado está en que a medida que se incrementan este tipo de métodos o bloques en una aplicación, mayor es la posibilidad de que en algún punto del programa durante la ejecución del mismo se presenten los conocidos DeadLocks que hacen que la aplicación entre en un loop infinito obligando a que sea reiniciada. 

En concreto un DeadLock ocurre cuando como mínimo dos hilos intentan simultáneamente asegurar un objeto que el hilo contrario ya tiene. Para ser más claro expondré un ejemplo, el hilo A obtiene el Lock  del objeto1 (o asegura el objeto1) mientras el hilo B obtiene el Lock del objeto2, seguidamente el hilo A intenta obtener el Lock del objeto2 antes de liberar el Lock del objeto1, al mismo tiempo el hilo B intenta obtener el Lock del objeto1 antes de liberar el Lock del objeto2, lo que tenemos aquí es que el hilo  A  esperara hasta que el hilo B libere el Lock del objeto2  mientras el Hilo B está esperando a que el hilo A libere el Lock del objeto1 y así se quedaran esperando el uno al otro hasta el día del juicio final o hasta que alguien reinicie la aplicación o la maquina. Veamos el ejemplo en código:     


  demonios java | hilos | Locks | DeadLocks | concurrencia
Comentarios 0Visitas: 885  


Encuentranos en FaceBook

Blog

« <July - 2010> »
SunMonTueWedThu FriSat
    123
45678910
11121314151617
18192021222324
25262728293031
Today

Enlazes de interes