Unas pistas para el problema de concurrencia

Éste artículo es una traducción al castellano de la entrada original publicada, en inglés, por Dr. Heinz Kabutz en su número 241b de The Java^tm Specialists’ Newsletter. Puedes consultar el texto original en Javaspecialists’ Newsletter #241:b Concurrency Puzzle Useful Hints

Este artículo se publica traducido en adictos, con permiso del autor, por David Gómez García, (@dgomezg) consultor tecnológico en Autentia, colaborador de JavaSpecialists y instructor certificado para impartir los cursos de JavaSpecialists.
[/box]

Un problema de concurrencia – Unas pistas útiles.

Muchas gracias a todos los que ya me han enviado por correo su solución al problema de la semana pasada. La mayoría de las respuestas eran correctas en teoría, pero incorrectas en la práctica 🙂 . Por mi experiencia es mejor aprender practicando, más que observando a otro. Por eso, sacarás más beneficio intentando resolverlo que leyendo mi solución. Así que, si aún no lo has intentado o te has quedado bloqueado en algún punto, aquí te dejo algunas pistas útiles:

1. Podemos discutir la corrección utilizando el Java Memory Model (JMM). No obstante, la mayoría de los problemas de concurrencia que se pueden presentar con happens-before, early-writes, visibilidad, etc… son muy difíciles de reproducir. Seguramente nos sería difícil escribir un test que fallase de forma consistente con este. Esa es la primera pista.
2. La segunda pista pasa por no creer nunca lo que te dicen tus clientes que es el problema. La explicación con System.arraycopy() es claramente una «pista falsa». Para ser justos, Jack me lo envió como una posible explicación. No obstante, no miré al código de System.arraycopy() porque realmente no creía que la razón del fallo fuese a estar allí. Así que puedes ignorar el System.arraycopy(). Puedes comprobar que si arrancas con un array mayor de 1000, también falla.
3. Siempre que tratamos de resolver problemas de concurrencia, debemos ser capaces de reproducir el error primero. Esto puede implicar que necesitemos buscar otro hardware que muestre el problema (es lo que yo hice). Una vez que lo ves producirse, cambia el código poco a poco comprobando si todavía se reproduce.
4. Última pista. La solución a este problema es increíblemente simple. De veras, cualquier desarrollador Java puede solucionarlo, no sólo los gurús de la concurrencia. Hay un pequeño efecto colateral que está prohibido con Swift 3 y que es el que causa la condición de carrera. No hay más pistas 😉

También sugerí que utilizases StampedLock para escribir este código de forma correcta. Admito que esto es un poquito más difícil que resolver el problema. StampedLock tiene tres formas base de utilizar add(), remove() y get() según su JavaDoc. Cuando lo tengas, por favor, envíamelo por correo y tendrás tu oportunidad de contribuir a nuestra solución y poner tu nombre en los créditos.

Saludos

Heinz.