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
>
>
|