Re: Removing a layer of synchronization on Math.random

2010-06-07 Thread Martin Buchholz
On Mon, Jun 7, 2010 at 19:46, David Holmes wrote: > Martin, > > CR 6959259 filed. Thanks. >> Then I noticed that StrictMath.random duplicates >> the code from Math.random, so I updated >> StrictMath.random as well.  It would be more >> maintainable to have StrictMath.random >> simply call Math.r

Re: Removing a layer of synchronization on Math.random

2010-06-07 Thread David Holmes
Martin, CR 6959259 filed. > Then I noticed that StrictMath.random duplicates > the code from Math.random, so I updated > StrictMath.random as well. It would be more > maintainable to have StrictMath.random > simply call Math.random; I can do that, > but other StrictMath methods do no such deleg

Re: Removing a layer of synchronization on Math.random

2010-06-07 Thread Martin Buchholz
On Sun, Jun 6, 2010 at 02:59, Rémi Forax wrote: > I think initRG can be written like that: > > private static synchronized Random initRNG() { >Random randomNumberGenerator = this.randomNumberGenerator; >   return (randomNumberGenerator == null)? this.randomNumberGenerator = new > Random() :

Re: Removing a layer of synchronization on Math.random

2010-06-06 Thread Rémi Forax
Le 06/06/2010 00:45, Martin Buchholz a écrit : Thanks to all the reviewers who were too polite to say: """What was Martin thinking?""" For some reason I had imagined that Math.random() was itself synchronized. After editing, I have a very small change that is hardly worth doing except that I a

Re: Removing a layer of synchronization on Math.random

2010-06-05 Thread Martin Buchholz
Thanks to all the reviewers who were too polite to say: """What was Martin thinking?""" For some reason I had imagined that Math.random() was itself synchronized. After editing, I have a very small change that is hardly worth doing except that I already have a webrev. http://cr.openjdk.java.net

Re: Removing a layer of synchronization on Math.random

2010-06-05 Thread Eamonn McManus
It seems to me that if two threads call this Math.random() at the same time then two instances of Random() can be constructed. That contradicts the specification of the method, and is theoretically observable because the two values from Math.random() will typically not be a pair of values that

Re: Removing a layer of synchronization on Math.random

2010-06-05 Thread Doug Lea
> Here's an optimization for Math.random() that appears to be safe, > despite the double-check access: > It is just barely safe because of Random internals that preclude reordering of the field ref assignment. It would be nicer (and no slower) to put a Fences.orderWrites() here. Assuming we add Fe