Sender: |
|
Date: |
Fri, 4 Jan 2008 04:22:15 -0500 |
MIME-version: |
1.0 (Apple Message framework v752.3) |
Reply-To: |
|
Content-type: |
text/plain; charset=US-ASCII; delsp=yes; format=flowed |
Subject: |
|
From: |
|
In-Reply-To: |
|
Content-transfer-encoding: |
7bit |
Comments: |
|
Parts/Attachments: |
|
|
On Jan 3, 2008, at 4:15 PM, Maciej M. Latek wrote:
> Exception in thread "Thread-11"
> java.lang.ArrayIndexOutOfBoundsException: 624
> at ec.util.MersenneTwisterFast.nextInt(MersenneTwisterFast.java:
> 1145)
MersenneTwisterFast is explicitly NOT threadsafe. If you are using
multiple threads, you will break the generator if they all call it
simutaneously.
> It is easy to pinpoint what is happening, but I'm not sure what
> would be best way to proceed. Each steppable in sequence makes
> numerous calls to nextInt() (in excess of 100 per step per each of
> 4-8 threads). What would be the best option (most efficient) to
> choose: a) have separate random number generators for each of the
> threads b) synchronize access to nextInt(n) on some external objext
> c) make version of MersenneTwisterFast that allows for concurrent
> access (by adding synchronized keyword to nextInt(n), my preferred)?
"a" is bad. You should only have separate random number generators
if you have truly random separate seeds, which you likely will not.
"c" is fine if you want a quick hack but BAD if you want any future
compatability -- keep in mind that MTF is nonthreadsafe for a *reason*.
"b" is definitely best. In fact, I have a great object for you to
synchronize on: the random number generator. As in:
int i;
MersenneTwisterFast rand = state.random; // locals are a little faster
// do this a 100 times...
synchronized(rand) { i = rand.nextInt(); }
This works great -- and is how RandomSequence works btw -- as long as
*all* of your parallel threads are synchronizing on the same object.
When using only one thread, don't synchronize.
> In a related matter: I have a rather lengthly setup process for my
> simulation (start() method in SimState reads plenty of data from
> disk). I noticed that when running in GUI mode, I can sometimes
> hang the whole process by clicking / focusing / resizing / moving
> some of the windows (controller or displays) when simulation sets
> up. Sometimes this would also happen during runtime. Is there a
> simple fix to it?
I'm interested in seeing this happen. Moving or resizing windows
causes repaint events, window events, and mouse events. Thing is,
start() is called in the simplest way possible: when you press the
Play button. This of course happens inside a mouse event in the GUI,
in a single thread, so you I think it should be impossible for MASON
to receive events and thus hang in any weird way.
This means that either a queued up collection of mouse or window
events is freaking out MASON *after* start() has completed
(unlikely), or that it's a bug in your Java implementation (more
likely -- are you using Windows? Have you tested on Linux and/or
MacOS X?)
BTW, make sure you're calling super.start() first.
Sean
|
|
|