There is no seed specified in 1.8 source code (see call to default Random's constructor in RandomController.java). According to Java documentation, this implies that the actual seed is System.currentTimeMillis(). So the seed should change each millisecond (although not all systems have the same time resolution - typically 50ms precision with Windows I've been told; however, I had the same strange RandomController behavior with Solaris8).
Another explanation I imagine would be that all the RandomControllers use the same seed because they are all clones.

What about using/sharing a singleton Random instance (e.g. as a static member of RandomController)?
It would solve the problem and avoid creating a lot of objects.
What do you think?

-- Bruno.

Manko, Gerard wrote:

Just a guess, but maybe all instances of the Random class are being created with the same seed?

Gerard

------------------------------------------------------------------------

This may be due to the the Random class works. I'd have to look it up, but each thread gets its own instance of RandomController, each of which creates an instance of Random on instantiation. However, if this all happens quickly, then each Random instance may be providing the same list of random numbers. Like I said, it's hard to tell since I don't know how Random works.
Other than that, I have no explanation - all the variables are non-static, and RandomController gets cloned for each thread. The fact that it extends InterleaveController has nothing to do with it far as I can tell.

-Mike

On 19 Dec 2002 at 14:18, Scott Eade wrote:


RandomController extends InterleaveController.  While it makes sense for
Interleave controller to apply across all threads, I somehow expected that a
Random controller would be applied on a per thread basis.  To be more
specific, here is the current behaviour:

Random Controller
   Request 1
   Request 2
   Request 3

If I have 1 loop and 20 threads, all will execute the same request (which
will be chosen randomly).

What I was expecting was for each of the 20 threads to be randomly be
allocated to one of the three requests.


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to