[concurrency-interest] TLR Puzzle

[Doug Lea]

On 02/18/2014 10:36 AM, Dr Heinz M. Kabutz wrote:
> A little newsletter on this subject to warn my readers to never let their
> ThreadLocalRandom instances escape.
> http://www.javaspecialists.eu/archive/Issue218.html

Thanks. Here's added javadoc that should someday be folded
in. We still do not want to specify exactly what happens if
you leak this or any other thread-local, since this might
be subject to change over time in either TLR or ThreadLocal.

    * tasks (for example, each a {@link ForkJoinTask}) use random numbers
    * in parallel in thread pools.
    *
!  * <p>Usages of this class should typically be of the form:
!  * {@code ThreadLocalRandom.current().nextX(...)} (where
!  * {@code X} is {@code Int}, {@code Long}, etc).
!  * When all usages are of this form, it is never possible to
!  * accidently share a {@code ThreadLocalRandom} across multiple threads.
    *
    * <p>This class also provides additional commonly used bounded random
    * generation methods.
--- 33,47 ----
    * tasks (for example, each a {@link ForkJoinTask}) use random numbers
    * in parallel in thread pools.
    *
!  * <p>Usages of this class should typically be of the form: {@code
!  * ThreadLocalRandom.current().nextX(...)} (where {@code X} is {@code
!  * Int}, {@code Long}, etc).  When all usages are of this form, it is
!  * never possible to accidentally share a {@code ThreadLocalRandom}
!  * across multiple threads.  As is the case for any thread-local
!  * variable, a {@code ThreadLocalRandom} should never be made
!  * accessible to other threads by, for example, holding in a {@code
!  * static} field. A {@code ThreadLocalRandom} used by multiple threads
!  * need not (and typically will not) generate uniform random numbers.
    *