ThreadLocalRandom.nextSecondarySeed() re-initializes TLR's seed

Peter Levart peter.levart at gmail.com
Thu Jun 19 08:48:24 UTC 2014


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
>




More information about the core-libs-dev mailing list