Ah, I didn't see the call to next.  The java docs do say that is the
implementation for that method, but they are lying:

    protected int next(int bits) {
        long oldseed, nextseed;
        AtomicLong seed = this.seed;
        do {
            oldseed = seed.get();
            nextseed = (oldseed * multiplier + addend) & mask;
        } while (!seed.compareAndSet(oldseed, nextseed));
        return (int)(nextseed >>> (48 - bits));
    }

On Dec 2, 8:05 am, Stuart Halloway <[EMAIL PROTECTED]> wrote:
> nextDouble calls next, which according to Java 5 docs is:
>
> synchronized protected int next(int bits) {
>         seed = (seed * 0x5DEECE66DL + 0xBL) & ((1L << 48) - 1);
>         return (int)(seed >>> (48 - bits));
>   }
>
> This is exactly the kind of thing I think we shouldn't have to worry  
> about in Clojure.
>
> Stuart
>
> > Looks like the only synchronization is for lazy initialization of the
> > instance of Random used by the static method:
>
> > public final class Math {
>
> >    private static Random randomNumberGenerator;
>
> >    private static synchronized void initRNG() {
> >        if (randomNumberGenerator == null)
> >            randomNumberGenerator = new Random();
> >    }
>
> >    public static double random() {
> >        if (randomNumberGenerator == null) initRNG();
> >        return randomNumberGenerator.nextDouble();
> >    }
>
> > }
>
> > public class Random implements java.io.Serializable {
> >    public Random() { this(++seedUniquifier + System.nanoTime()); }
> >    private static volatile long seedUniquifier = 8682522807148012L;
>
> >    public double nextDouble() {
> >        long l = ((long)(next(26)) << 27) + next(27);
> >        return l / (double)(1L << 53);
> >    }
> > }
>
> > On Dec 2, 12:04 am, Stuart Halloway <[EMAIL PROTECTED]> wrote:
> >> Clojure's rand delegates to Java's Math.random(), which I am pretty
> >> sure has a synchronized block in it.
>
> >> One problem with living on top of Java is calling into methods that
> >> have no (conceptual) need to be synchronized. This could hurt
> >> performance in an app carefully written in Clojure to avoid mutable
> >> state and locking. Since unsynchronized PRNGs exist, I would suggest
> >> we modify rand to use one. (I am willing to take the lead on writing
> >> one in Clojure if needed.)
>
> >> Thoughts?
>
> >> Stuart
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to