[concurrency-interest] ThreadLocalRandom

Joshua Bloch josh at bloch.us
Tue Jan 13 02:02:41 EST 2009


If you're going to go that route, make it an interface (which it should have
been in the first place).  Then Random, SecureRandom, and ThreadLocalRandom
can implement it.  And we can add static factories to return high-quality
PRNGs instead of the not-quite-state-of-the-art PRNG specified by
java.util.Random.  Of course this would have been more effective if we'd
done it in 1997 but c'est la vie.
         Josh

On Mon, Jan 12, 2009 at 10:26 PM, Jeremy Manson <jeremy.manson at gmail.com>wrote:

> This seems a little weirdly backwards to me (although I'm sure you had
> a good reason to do it this way).  Given that (I assume) you can't
> change the class hierarchy to add a superclass for Random, why didn't
> you extract the actual random number generation logic into a delegate
> class and have both Random and ThreadLocalRandom point to that class?
>
> Jeremy
>
> On Mon, Jan 12, 2009 at 9:31 AM, Doug Lea <dl at cs.oswego.edu> wrote:
> >
> > As probably the final refactoring pass on Java7 versions of ForkJoin etc
> > the thread-local random generator was pulled out into a stand-alone
> class.
> > Class ThreadLocalRandom is useful in most situations where people use
> > java.util.Random across multiple threads. It is a subclass of Random,
> > but has no constructor -- instead a static "current()" method to
> > get the one for the current thread. It also doesn't let you change
> > the seed. (So people who need thread-local generators with explicit
> > seed control can't use it.)
> >
> > The main reason for using it is performance, including performance
> > testing. Using a contended shared Random will often be 10X slower,
> > and mask the performance differences you are actually looking for.
> > (Some SPEC benchmarks have had this problem.)
> >
> > See:
> >
> http://gee.cs.oswego.edu/dl/jsr166/dist/jsr166ydocs/jsr166y/ThreadLocalRandom.html
> >
> > Comments welcome.
> >
> > Also, as we move closer to jdk7 (openjdk) integration,
> > anyone wanting to help with code or documentation reviews
> > ot testing might want to take a look. See links from
> > http://gee.cs.oswego.edu/dl/concurrency-interest/index.html
> >
> > -Doug
> > _______________________________________________
> > Concurrency-interest mailing list
> > Concurrency-interest at cs.oswego.edu
> > http://cs.oswego.edu/mailman/listinfo/concurrency-interest
> >
> _______________________________________________
> 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/20090112/e40fb934/attachment-0001.html>


More information about the Concurrency-interest mailing list