LISTSERV mailing list manager LISTSERV 16.0

Help for MASON-INTEREST-L Archives


MASON-INTEREST-L Archives

MASON-INTEREST-L Archives


MASON-INTEREST-L@LISTSERV.GMU.EDU


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Proportional Font

LISTSERV Archives

LISTSERV Archives

MASON-INTEREST-L Home

MASON-INTEREST-L Home

MASON-INTEREST-L  August 2007

MASON-INTEREST-L August 2007

Subject:

Re: Further updated Schedule.java

From:

Sean Luke <[log in to unmask]>

Reply-To:

MASON Multiagent Simulation Toolkit <[log in to unmask]>

Date:

Thu, 16 Aug 2007 13:15:03 -0400

Content-Type:

multipart/mixed

Parts/Attachments:

Parts/Attachments

text/plain (5 lines) , GUIState.java (5 lines) , Unknown Name (89 lines)

D'oh!  Minor bugs due to some cleanups I did in Schedule.  GUIState's  
easy to fix on the fly:

	


... will clean up the other one later (or maybe put back the constructor). None of this is out on CVS yet though. Further tests would be welcome everyone. Sean On Aug 16, 2007, at 1:05 PM, Maciej M. Latek wrote: > 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 >> >>

Top of Message | Previous Page | Permalink