On Thu, May 10, 2012 at 12:45 AM, Sean Luke <[log in to unmask]> wrote:
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. ...

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.

Actually this is without a GUI. :(

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).

Ok, I made this change and that seems to have resolved the deadlock problem.  I can commit these changes to MASON, if you'd like.

(And now I'm back to ye olde race condition that's occurring within the simulation itself.  *sigh*)

> (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.

Just as an aside to anyone else reading this, I boned up on java concurrency support here: http://www.javamex.com/tutorials/synchronization_concurrency_1.shtml  Lotsa good stuff there.  I also spent some time noodling about here: http://www.javapractices.com/home/HomeAction.do#Threads

(And it's where I learned about some of the new concurrency support features.)

> (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.

My first hint that this was a potential problem was that the IDE was whining about synchronizing on a non-final object.  Usually its complaints are well founded, so I did a little research.  Apparently the problem is that it's possible to pull a switcheroo on synchronized non-final objects.  So, say, you synchronize on A in one thread, and meanwhile change the value of A in another and synchronize on that even though they're for the same variables -- now A is no longer an effective lock.  If A is final then the switcheroo isn't possible.

However, the warning can be ignored here because the boolean array lock in Schedule is protected and doesn't change value once set as far as I can tell. However because it *is* protected it's possible for a subclass to do naughty things with it.