I don't know if this will be helpful in your application, or even if it's the best approach for our own work (or if java 1.7 provides a simpler approach?), but FWIW one of my projects deals with the thread-local RNG issue via: https://clojars.org/clj-random
-Lee On Jun 6, 2014, at 12:28 PM, Mars0i <marsh...@logical.net> wrote: > I'm writing an agent-based simulation framework, in which agents are Clojure > records called Persons. There are 40-100 persons at present, but conceivably > the number could go up to 1000. In each timestep, Persons' states are > functionally updated by mapping update functions across the collection of > Persons. The application is designed to be able to run in a single thread, > or to be run in multiple threads, depending on whether I do the mapping using > map or pmap. (The application is generally faster with pmap (and all I had > to do was add "p"), but I think there might be contexts in which > single-threaded operation is preferable.) > > At one point in the Person-update process, each Person randomly samples a > small number (1 to 50) of elements from some small collections (size 10 up to > the max number of persons). When the application is multi-threaded, I'd > rather not have separate threads accessing the same random number generator. > (Java 1.7 allows a way of dealing with that, but for now I'd rather be > compatible with Java 1.6 as well.) > > Does the following solution make sense? > > 1. During initialization, I'll get a random number generator from > java.util.Random, initialized with the system time or something else that > varies. > > 2. I'll give each person a field :rng, and will initialize each one with a > sparate call to java.util.Random, with a seed determined by the RNG mentioned > in the previous line. (After this I can let the inititial RNG to be garbage > collected.) > > 3. During the steps in which each Person needs to sample from collections, > the code will get the RNG from the Person's :rng file, and use it to > determine what elements are sampled. > > There is more than one way that I could implement step 3. Here are some > options I'm considering: > (a) Bind data.generators/*rnd* to the RNG, and then call functions in > data.generators. > (b) Pass the Person's RNG to functions from bigml/sampling (which allow you > to pass in an RNG). > (c) Write my own sampling functions that use the RNG from the Person. > > Further remarks: > > When the application is single-threaded, each Person will use a different > RNG, which isn't necessary, but it won't hurt, since the RNGs will have > different seeds, except that I waste memory by creating multiple RNGs. When > the application is multi-threaded, I still don't need one RNG per person, > strictly speaking, since the number of threads will be much less than the > number of Persons. However, giving each Person its own RNG is simpler. It > means that my code can ignore threads and let Clojure figure out how to > manage them. > > > What do you think? Thanks in advance for any help. -- 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 Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
