On Sep 26, 2011, at 12:54 AM, Roger Worden wrote:

> Since I'll be running several hundred "trials", I set breedthreads and 
> evalthreads to try to optimize my run times. Unfortunately I'm seeing different 
> evolution behavior with multiple threads than with a single thread. I have five 
> subpopulations, all defined identically. When I run single-threaded, subpop 0 
> always* gets a better fit, sooner, than do the other subpops. Subpops 1-4 
> struggle to reach the fitness of subpop 0, but rarely reach it. They often (but 
> not always) show a declining fitness, i.e. 1 is better than 2 is better than 3, 
> but sometimes that curve evens out over time. If I run the same trials and 
> change the threading, no changes to the subpopulations whatsoever, all five 
> evolve evenly. Unless I'm misunderstanding something, this would seem to be 
> a bug... has anyone reported such behavior? Or is there some valid reason 
> why subpop 0 should get more "attention" or evolve (faster, better) in a 
> multithread run?

Roger, it's hard to tell exactly what's going on here.  It could be a bug but doesn't smell like it.  I'd need a working example to make any progress, ideally one that's fairly minimal.  I'm not sure how you're doing multipopulation evolution: are you using the coevolution package, for example?  Or just running with N populations? 


> On a related note, is the number of the subpopulation to which an individual 
> belongs, or the thread the evaluation is running in, available as a property or 
> variable visible to the fitness evaluation method?

SimpleProblemForm.evaluate(...) pass in both the thread number and the subpopulation number.


> Is there any relationship (affinity) between threads and subpops?

No.


> I had set up some static variables in 
> my fitness method to help with reporting and overall monitoring of progress, 
> and when I run multithreaded these are getting corrupted and confused.  What 
> does a "static" variable mean in a multithreaded run?

Static variables are essentially global variables.  All threads can see them and scribble to them, and in any order.  This is a race condition.

> If I can detect the 
> thread number (more likely) or subpop number (less likely), maybe I can 
> make my monitoring variables thread-safe.

You could make an array indexed by thread number (the size of the array must be the maximum of your breed threads and eval threads). Alternatively you could synchronize the variables involved (see the "synchronized" keyword in various Java documentation).

Sean