Opinion / Interrupts de Threads
Quería probar Interrupts del ejemplo , así que decidí emular el clásico Control-C usando . La intención de ponerlo es para tener sus observaciones, opiniones, etc. También me gustaría saber más sobre como usar Interrupts, donde usarlo o todos los tips que se les ocurran.
Conociéndome, cuando tenga que hacer algo así usare este método y no se si es lo conveniente o correcto.
Por ejemplo: Cuando una aplicación procesa miles de registros de una base de datos y los arroja a la terminal, de repente vemos el dato que deseamos (por más rápido que se imprima en pantalla heee) y guala con un Control-C terminamos el proceso. Solo que en ves de miles de registros uso caritas, y en ves de Control-C comparo un String.
Bueno pues muchisimas gracias por el tiempo a todos... bye.
EDIT: La definición de la clase y atributos no concuerda con el propósito del ejemplo, algo que no interfiere pero incomoda : ) sorry...
- Inicie sesión o regístrese para enviar comentarios
Ese parecería un escenario
Ese parecería un escenario bueno, detener el hilo cuando se desea.
Generalmente cuando se quiere hacer que un hilo haga algo por determinado tiempo se pone una condición ( como ayer que estabas buscando que fuera el número 2 ) Pero en este escenario donde no sabes cuando hay que parar, usar Interrupt parece adecuado.
Quizá el único inconveniente es que tienes que tener una referencia al hilo que deseas detener, otro inconveniente ( este mucho menos importante ) es que puedes ignorar la señal de detenerse, digo menos importante, porque se supone que tu sabes dentro de tu programa si un hilo ha de detenerse o no.
El el documento que mencionas, también está listada la opción:
Que es otra forma de ver si ha de detenerse la ejecución o no del thread.
Cuando se habla de concurrencia en Java, este libro surge reiteradamente:
Si lo compras, luego me lo prestas para ojearlo.
Doug Lea, uno de los autores fue quién escribió gran parte del paquete java.util.concurrent.
También esta este artículo que algún día leeré:Concurrent progamming with J2SE 5.0
Saludos
Vientos Oscar, gracias por
Vientos Oscar, gracias por los tips :D. Si no lo deje con el
Y esto nos arroja:
Pero me llama mucho la atención ( casi todo jejeje) lo que usa @Ezamudio en este articulo y que aparece en el que manadas te Atomic variables: The java.util.concurrent.atomic package...
Me la voy a llevar tranquila si no me engolosino :D.
No te entendí a que te
No te entendí a que te refieres con eso de manadas de Atomic variables Te sale eso cuando ejecutas o que?
Ok. :S
Oscar lo siento :S. Las prisas como siempre. Pues que me interesa mucho entender el tema de como usar las Atomic variables, como en estas ligas mencionan y entre otras más claro:
Mentiría si te digo que se para que se usan sólidamente y solo me falta aprender a usarlas jejeje, pero bueno me tomare mi tiempo para ir de lo básico a lo más complejo y echare un par de preguntas a la comunidad. Vale pues suerte : ).
Tampoco es muy
Tampoco es muy complejo.
Tienes un objeto. Este objeto tiene un atributo "contador" ( un entero por ejemplo ). Si el atributo de este objeto es accedido por dos o más hilos, se requiere sincronizar el acceso para que tengas resultados consistentes. Ejemplo:
Si el thread 1 y el thread 2 tienen acceso a ese objeto, alguno de los dos podría hacer lo siguiente:
El problema está en que el otro thread, puede "ver" el valor incorrecto, puede ser que vea el valor antes del incremento o después.
Para solucionarlo se puede usar el acceso sincronizado ( donde solo un thread puede modificarlo a la vez )
La desventaja es que si tienes digamos 100 threads y todos quieren hacer esto, todos se van a embotellar aquí, queriendo ganar el lock del objeto "o"
O... se puede usar un AtomicInteger
La diferencia es que así se puede acceder al atributo sin necesidad de sincronizar el acceso ( evitando cuellos de botella por ejemplo ) y al mismo tiempo garantizando que el incremento sea "atomico" ( o sea de un solo jalón pues )
Lo mejor ( más sencillo ) sería por supuesto, que este valor no estuviera compartido entre tantos threads y que ellos trabajaran de forma independiente, pero a veces, esto no es posible.