[concurrency-interest] TLR Puzzle

Ben Evans benjamin.john.evans at gmail.com
Wed Feb 5 08:33:59 EST 2014


Could we do 1 and / or 2 in time for JDK 8, as it just requires a
documentation patch?

Then we can add rules to the static analysis checkers (as they aren't
dependent on the JDK release cycle) and that should catch a decent amount
of people.

Thanks,

Ben


On Sat, Feb 1, 2014 at 8:32 PM, Doug Lea <dl at cs.oswego.edu> wrote:

>
> To summarize, we have the following suggestions (some off-list)
> in response to Heinz's puzzler:
>
> 1. Add documentation to TLR warning not to store TLR.current()
> in a static, or use as an argument to a method that might do so,
> or use as an argument in a method assuming thread-safety.
>
> 2. Add similar documentation to java.lang.ThreadLocal, and then
> refer and add to it in TLR.
>
> 3. Create findBugs rules covering (1) and (2).
>
> 4. Invent new type rules for Java enforcing (1) and (2).
>
> 5. Add an initialization check on each use of TLR.next() and
> throw an exception.
>
> 6. Eagerly initialize TLR seeds. (One reason this was not
> done originally is that it adds measurable time to Thread
> construction even when TLRs are not used in a thread, which
> is the most common case.)
>
> 7. Tell people to use java.util.SplittableRandom instead.
>
> 8. Do nothing.
>
> Considering that this is far from a critical bug, it is
> unlikely to become updated in OpenJDK until JDK9, so we
> seem to have plenty of time for further suggestions!
>
> -Doug
>
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20140205/3b2ea2da/attachment.html>


More information about the Concurrency-interest mailing list