Subject: | |
From: | |
Reply To: | |
Date: | Thu, 10 May 2012 14:11:48 -0400 |
Content-Type: | text/plain |
Parts/Attachments: |
|
|
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
|
|
|