On Mon, Dec 12, 2011 at 2:49 AM, Ted Dunning <ted.dunn...@gmail.com> wrote:
> > > Why would the caller care? It's all random numbers, whether "reset" or > > not. > > > > The care is about determinism. > Completely agree, it's the tests that care, not the caller itself. > If the RandUtils notes that the current thread stated we are in test mode > before asking for a random number generator then it can return a random > generator with the test seed. Otherwise, it can return a more robustly > seeded generator. The generators in separate test threads are independent > objects with independent state. > > Just noting the thread is in test mode doesn't do the trick -- the code already does what you describe. Are you talking about ThreadLocal? That is nearly the solution, though it still involves static members. The performance overhead of using ThreadLocal is probably quite small here, no problem. It does still need code surgery, as any Random potentially needs to be ThreadLocal<Random> unless you can know it is never shared. And any computation resulting from these can not be shared, likewise, or else the result changes in potentially nondeterministic ways in the presence of multiple threads. The knock-on effect is, I would guess, significant. In this regard I think it's the same challenge you get without ThreadLocal, but at least it gives you a way to share a Random across objects without having to share it across threads. I do agree this is all possible in principle, just not in practice, here. My guess is that there will be some shared state that just can't be un-shared without a lot of work, or so much more change (many more ThreadLocals) that it is unpalatable. And of course, it just takes one new bit of code not doing this all right to make tests non-deterministic again -- you can police it but even "new Random()" is being written in new code today My guess is this is "virtually impossible" but that is just a guess -- brave souls welcome to try a patch after noting the above and see how it flies. It *seems* so much more like a test issue to me, solvable in the test harness, and in a clear way: just split tests n ways across n JVMs instead of 1 JVM with n threads. No (further) reliance on code being exactly well behaved. It's just we don't have a one-liner to do that. Compared with seasoning the code with ThreadLocal, and its associated small overhead, and all the work to do that surgery, just feels very much like the hard way to solve this.
