For what it is worth, I implemented (for another project) George Marsaglias XorShift algorithm (as recommended in Java Concurrency in Practice) in a thread-safe contention free maner, by making the thread-id part of the source entropy. This way, two threads will generate different random numbers from the same seed. And when a thread see a seed written by another thread, then that is just another source of entropy.
The implementation has two drawbacks compared java.util.Random: * It's a "medium quality" algorithm, whatever that means, and I _presume_ that whatever is in java.util.Random is high quality. But I have not had any problems with lack of randomness by the implementation. * If you want to share an instance between threads, then it's _your_ responsibility to guarantee safe publication. Link: http://github.com/karmazilla/nanopool/tree/master/src/main/java/net/nanopool/CheapRandom.java On Tue, Dec 2, 2008 at 4:25 PM, Lauri Pesonen <[EMAIL PROTECTED]> wrote: > > 2008/12/2 Stuart Halloway <[EMAIL PROTECTED]>: >> >> Cool, that's much better. Can we establish that all (or all important) >> Java 5+ VMs use AtomicLong in next? > > While compare-and-swap is a lot better than a mutex, it's still not > free. IIRC a CAS is one (or maybe two) order(s) of magnitude more > expensive than a normal store. So a non-threadsafe PRNG should still > give you a performance boost compared to the CAS-version. But, as you said, > this is all speculation until someone writes some tests... > > -- > ! Lauri > > > > -- Venlig hilsen / Kind regards, Christian Vest Hansen. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
