random streams (original) (raw)

Doug Lea dl at cs.oswego.edu
Mon Dec 31 11:32:42 PST 2012

On 12/31/12 14:18, Brian Goetz wrote:

Sharing random number generators is indeed a tricky thing. But, this doesn't change the status quo, it just wraps it differently. Doing:

rng.ints().parallel().forEach(i -> { ... i ... }) is no different from submitting code like { ... i = rng.nextInt(); i ... }) to an FJP; you'll get exactly the same interleavings.

You might recall that the reason for introducing TLR in JDK7 was that people using FJ/ParallelArray were reporting horribly contention problems. (Initially, thread-local randoms were available only as a utility method in FJ, then made stand-alone for JDK7.) We'd sorta rather not let this lesson be lost :-)

ThreadLocalRandom can override this to implement: public IntStream ints() { return PrimitiveStreams.repeatedly( () -> TLR.current().nextInt()); }

How about ONLY adding to TLR?

-Doug

On 12/31/2012 1:54 PM, Doug Lea wrote: On 12/31/12 13:41, Brian Goetz wrote: On the list of requested stream sources is 'stream of random numbers'. Here's a one-line addition to Random: public IntStream ints() { return PrimitiveStreams.repeatedly(this::nextInt); } Certainly the implementation is straightforward enough (modulo renaming of PrimitiveStreams and repeatedly, which are not yet nailed down.) This is not so straightforward under parallel operations. This is a surprisingly deep topic with a lot of technical papers etc. As a first pass, you'd just use ThreadLocalRandom() as sources (to avoid horrible update contention), and make no promises about the aggregate randomness across parallel operations. However, people will come to expect that if you start off computations with a common seed, then you get both replicability and independence, which is not easy to deliver. As a start, you'd need a better generator than the one in Random (which is and must be the same algorithm used in ThreadLocalRandom). -Doug

More information about the lambda-libs-spec-experts mailing list