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