On Thu, May 10, 2012 at 12:45 AM, Sean Luke <[log in to unmask]>
On May 9, 2012, at 11:57 PM, Mark Coletti wrote: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'm having problems with a MASON simulation whereby I have a ParallelSequence of RandomSequences that seems to deadlock on the RNG. ...
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.
(And it's where I learned about some of the new concurrency support features.)
You'll have to be more specific. Generally the issue on synchronizing is not finality but privacy. Interesting issues crop up regarding serialization.
> (Also, there is some synchronizing on non-final fields badness, such as the boolean array lock object.)
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.