Sir,

1) When run with the GUI, the error occurs (it seems to run with GUI
less simulation though):

Exception in thread "AWT-EventQueue-0" java.lang.Error: Unresolved
compilation problem:
	The method isThrowingScheduleExceptions() is undefined for the type Schedule

	at sim.display.GUIState.scheduleImmediate(GUIState.java:459)
	at sim.display.GUIState.scheduleImmediateRepeat(GUIState.java:508)
	at my GUIState derivative class

2) At the same time, constructor Schedule(int) is undefined, which
causes some of the demos not to run (Mousetraps for example).

Regards

Maciek









Regards

Maciek



On 8/13/07, Sean Luke <[log in to unmask]> wrote:
> Here's a further revised Schedule for anyone interested.  Totally
> experimental -- indeed, basically untested.  It's been modified in
> the following way.
>
>         - Any thread can now schedule things on the schedule at any time,
> even while schedule.step() is running.
>         - Any thread can now call reset() or simstate.kill(), but be advised
> that other threads could theoretically add new things on the schedule
> even after it's been reset, thus nullifying the point of reset() or
> kill().
>         - Any thread can call time() (or a new identical method, getTime())
> or getSteps()
>         - schedule.step() explicitly looks for reentrancy and denies it
>         - I've deleted the numOrders constructor.  It's time.
>         - I've deleted the throwsExceptions option.  A bit faster and
> cleaner.  It's time.
>
> I do this by employing two locks: (1) the Schedule itself, whose
> synchronization controls access to step() to prevent some race
> conditions, and (2) an internal lock which controls access to the
> time, steps, shuffling parameter, and heap.  Using this second lock
> allows some finer control over critical regions and thus makes
> possible the "any thread" stuff in the bullets above.
>
> It doesn't look much slower, so I may keep it.  But I won't add it to
> CVS without some major testing. Anyone up for it?
>
> To be threadsafe, AsynchronousSteppables and ParallelSequence still
> shouldn't call reset() or simstate.kill(), but rather should schedule
> a Steppable which calls simstate.kill().
>
>
>
> Sean
>
>