Print

Print


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