Or, even better, why not just using the next value from the "seeder" sequence for the initial value of "secondary" seed and avoid interaction with TLR's main seed/probe: diff -r 5b45a5efe417 src/share/classes/java/util/concurrent/ThreadLocalRandom.java --- a/src/share/classes/java/util/concurrent/ThreadLocalRandom.java Tue May 20 10:11:23 2014 +0400 +++ b/src/share/classes/java/util/concurrent/ThreadLocalRandom.java Thu Jun 19 10:45:25 2014 +0200 @@ -1034,8 +1034,7 @@ r ^= r << 5; } else { - localInit(); - if ((r = (int)UNSAFE.getLong(t, SEED)) == 0) + if ((r = (int)mix64(seeder.getAndAdd(SEEDER_INCREMENT))) == 0) r = 1; // avoid zero } UNSAFE.putInt(t, SECONDARY, r); Regards, Peter On 06/19/2014 10:37 AM, Peter Levart wrote:
Hi,
I noticed an inconsistency in calling TLR.localInit() method. Everywhere it's called conditionaly if thread-local "probe" is zero except in TLR.nextSecondarySeed() where it's called if "secondary" seed is zero. This re-initializes the "probe" and "seed" even though they might have already been initialized. It's not a big deal, because this happens at most once per thread, but it would be more consistent to call localInit() conditionaly, I think:
diff -r 5b45a5efe417 src/share/classes/java/util/concurrent/ThreadLocalRandom.java --- a/src/share/classes/java/util/concurrent/ThreadLocalRandom.java Tue May 20 10:11:23 2014 +0400 +++ b/src/share/classes/java/util/concurrent/ThreadLocalRandom.java Thu Jun 19 10:34:18 2014 +0200 @@ -1034,7 +1034,8 @@ r ^= r << 5; } else { - localInit(); + if (UNSAFE.getInt(t, PROBE) == 0) + localInit(); if ((r = (int)UNSAFE.getLong(t, SEED)) == 0) r = 1; // avoid zero }
Regards, Peter