MASON-INTEREST-L Archives

October 2007

MASON-INTEREST-L@LISTSERV.GMU.EDU

Options: Use Monospaced Font
Show Text 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:
Sun, 7 Oct 2007 09:49:43 -0400
Content-Type:
multipart/mixed
Parts/Attachments:
text/plain (120 bytes) , Schedule.java (29 kB) , text/plain (29 kB)
I think you're right.  But before you bother fixing it, test the  
newer version of Schedule.java out on CVS.  Here it is:




I have no doubt that the new Schedule.java has some bugs but would like to stomp them. It's got your bug fixed though. Sean On Oct 7, 2007, at 12:32 AM, Nicholas Radtke wrote: > I'm not sure if this is the correct place to post this question, > but since > there doesn't seem to be a developers' list, I thought I'd go ahead > and post > it here. > > I believe I've found a bug in sim.engine.Schedule in Mason 12. > Specifically, > there is a execution path that sets but never unsets the variable > inStep: > >> From Schedule.java: > > public synchronized boolean step(final SimState state) > { > inStep = true; > final double AFTER_SIMULATION = > Schedule.AFTER_SIMULATION; // a > little faster > > if (time==AFTER_SIMULATION) return false; > ... > } > > If time is AFTER_SIMULATION, then inStep, which was set to true at the > beginning of the method, is never set back to false. This appears > to be an > error, as it causes incorrect behavior in the following situation: > > for (i = 0; i < SOME_NUM; i++) > { > sim.start(); /* Add events to the schedule. */ > while(sim.step()); > sim.finish(); > } > > When i = 0, the while loop causes the simulation to run until the > end of the > schedule, resulting in time being set to AFTER_SIMULATION and the > above > step() code executing, leaving inStep = true. Next, sim.finish() and > sim.start() (via calls to their parent SimState classes' start() > and finish() > methods) result in calls to Schedule's pushToAfterSimulation() and > reset() > methods. Both of these methods check inStep, which is currently > true, and > set the variable killStep to true as a result. Now, any attempts > to add new > events to the just-reset schedule fail because the scheduleOnce() > method > checks the variable killStep and does not enqueue new events if > killStep is > true. Thus, the for loop will not work as expected the second time > when i = > 1 because it was not possible to add any events to the schedule. > > The fix seems to be straightforward. Replace > > if (time==AFTER_SIMULATION) return false; > > with > > if (time==AFTER_SIMULATION) > { > inStep = false; > return false; > } > > I've tested this fix and found no side effects... but that doesn't > mean there > aren't any. > > This problem looks like it has been fixed in the CVS version of > Schedule.java > that was posted to this list, but since the new version was > identified as > experimental, I thought I'd mention the bug here, in case others > don't want > to use the new untested version or the new version is rolled back > and not > included in the next stable release. > > Nicholas

ATOM RSS1 RSS2