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.

Cheers!

Mark