Subject: | |
From: | |
Reply To: | |
Date: | Sat, 6 Oct 2007 21:32:24 -0700 |
Content-Type: | text/plain |
Parts/Attachments: |
|
|
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
|
|
|