Even if you use a per-thread instance, you pay the synchronization
penalty. Because there is no contention, the penalty is lower, but it
is still not zero.
Is it big enough to matter? My intuition says "yes". That's worth
nothing, so I will write some tests when I have some spare time ...
but secretly I was hoping that this thread would goad someone else
into writing the tests and publishing their results. :-)
Stuart
> On Tue, Dec 2, 2008 at 3:05 PM, 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.
>
> The docs for Math.random() say:
>
> ; When this method is first called, it creates a single
> ; new pseudorandom-number generator, exactly as if by
> ; the expression
> ;
> ; new java.util.Random
> ;
> ; This new pseudorandom-number generator is used
> ; thereafter for all calls to this method and is used
> ; nowhere else.
> ;
> ; This method is properly synchronized to allow correct
> ; use by more than one thread. However, if many threads
> ; need to generate pseudorandom numbers at a great rate,
> ; it may reduce contention for each thread to have its
> ; own pseudorandom-number generator.
>
> So can't you just create multiple instances of java.util.Random if you
> need that sort of thing?
>
> --
> Michael Wood <[EMAIL PROTECTED]>
>
> >
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
