On May 9, 2012, at 11:57 PM, Mark Coletti wrote:



> I'm having problems with a MASON simulation whereby I have a ParallelSequence of RandomSequences that seems to deadlock on the RNG.  When creating the RandomSequences I did specify via the ctor argument that invocations of the RNG to do the shuffle should be synchronized.  (I.e., "shouldSynchronize" is true.)  I see in the debugger that all the ParallelSequence threads are waiting on sim.engine.Schedule, but I cannot find what else has a lock on that.  I *think* that the Schedule.step() itself has a lock on it, but I'm not sure if I'm interpreting the debugger display correctly.  My worry is this language in the RandomSequence documentation: "... and elsewhere in your embedded steppables you're synchronizing on the Schedule first (the Schedule is the basic lock point for MASON's models)."  I'm not sure what that means.  What embedded Steppables?  And where and when should they be synchronizing on Schedule?



Gaaah, I think I made an error.  If you're running without a simulation, it'll probably work fine to synchronize on state.schedule (which is what shouldSynchronize does).  But if you run under the GUI, the top-level model thread already has a lock on state.schedule, so you should be seeing a deadlock.



I have to Think Deeply upon this to fix things properly for you.  But in the meantime, you could hack around it -- perhaps unsafely -- by changing shouldSynchronize to synchronize on the random number generator rather than on the schedule.  (See the code for RandomSequence).





> As an aside, I'm curious on why there wasn't a synchronize on state.random, itself, instead of the scheduler if all we want to do is eliminate race conditions on the RNG.



Originally it was because there are other reasons you might synchronize on the model, such as in a GUI.  But I think that's a misfeature.  Let me Ruminate Upon It.





> (And one consideration for moving MASON up to Java 1.5 support are more concurrent software development goodies such as "volatile" now functioning as a mini-monitor for variables.)



Might be worthwhile.



> (Also, there is some synchronizing on non-final fields badness, such as the boolean array lock object.)



You'll have to be more specific.  Generally the issue on synchronizing is not finality but privacy.  Interesting issues crop up regarding serialization.



Sean