[concurrency-interest] TLR Puzzle

Zhong Yu zhong.j.yu at gmail.com
Wed Feb 19 14:51:45 EST 2014


Typically, a thread-local variable could be handed over to another
thread, with proper happens-before edge. The current impl of TLR
cannot do that due to its peculiar mechanism of initialization. So I
don't think it's enough to let users reason about it like a normal
ThreadLocal.

Here's an example:

    static ThreadLocalRandom random;

    public static void main(String[] args) throws Exception
    {
        Thread t1 = new Thread( () ->
            random=ThreadLocalRandom.current()
        );
        t1.start();
        t1.join();

        System.out.println( random.nextInt() ); // is the result random?
    }

Zhong Yu


On Wed, Feb 19, 2014 at 7:11 AM, Doug Lea <dl at cs.oswego.edu> wrote:
> 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.
>
>    *
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest


More information about the Concurrency-interest mailing list