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