MASON-INTEREST-L Archives

May 2012

MASON-INTEREST-L@LISTSERV.GMU.EDU

Options: Use Monospaced Font
Show HTML Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Sean Luke <[log in to unmask]>
Reply To:
MASON Multiagent Simulation Toolkit <[log in to unmask]>
Date:
Thu, 10 May 2012 14:11:48 -0400
Content-Type:
text/plain
Parts/Attachments:
text/plain (19 lines)
On May 10, 2012, at 1:25 AM, Mark Coletti wrote:

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

That's totally mystifying, because when you run without a GUI nothing locks on the schedule to create that deadlock.  There's gotta be something else to it.

That being said, I've done an update to the RandomSequence code and changed the rule about how to do locking for the random number generator.  Now if you are accessing the generator from different threads you should lock on the GENERATOR, not on state.schedule.  Note that you should STILL lock on state.schedule to handle synchronizing between the GUI and the underlying model, that's not changed.

I also updated the code in LocationLog -- it shouldn't print out anything if you have assertions turned on any more.  You have to also say    -DLocationLog   in order to get the printouts happening.

Sean

ATOM RSS1 RSS2