[concurrency-interest] TLR Puzzle
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
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
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!
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Concurrency-interest