MASON-INTEREST-L Archives

August 2007

MASON-INTEREST-L@LISTSERV.GMU.EDU

Options: Use Monospaced Font
Show Text Part by Default
Condense Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Sender:
MASON Multiagent Simulation Toolkit <[log in to unmask]>
Date:
Thu, 9 Aug 2007 23:18:29 -0400
Reply-To:
MASON Multiagent Simulation Toolkit <[log in to unmask]>
Subject:
From:
"Maciej M. Latek" <[log in to unmask]>
Content-Type:
multipart/mixed; boundary="----=_Part_13229_16223931.1186715909261"
In-Reply-To:
MIME-Version:
1.0
Comments:
To: MASON Multiagent Simulation Toolkit <[log in to unmask]>
Parts/Attachments:
text/plain (3999 bytes) , Schedule.java (29 kB)
First of all, thanks to Professor Luke for help.

1) A modified by Professor Luke version of Schedule is attached, If I
recall correctly, the major changes happend in the step method, with
minor revision of a number of ScheduleOnce(*) and ScheduleRepeating(*)
variants.
2) This version allows for calling schedule.time() (and
schedule.getSteps()) method from Steppables called from inside the
ParallelSequence.

Summarizing other possible workarounds of this problem:

3) To have the time available from the ParallelSequence using
unmodified MASON engine, one may extend the Steppables to have a time
field and use wrapper to set it before ParallelSequence get's called:

Xagent implements Steppable ..... {
double time;
}

and in the SimState start() method have something along following lines:

final Steppable parallelWrapper = new Steppable() {
public ParallelSequence agentSequence;
public void step(SimState state) {
for (int i=0; i < agentSequence.steps.length; i++) {
	((Xagent) agentSequence.steps[i]).timer = state.schedule.time();
}
agentSequence.step(state);
}
};
schedule.scheduleRepeating(parallelWrapper);

assuming proper initialization of agentSequence, the time field will
have the same value as the one received should calls to
schedule.time() be allowed (same hold for getSteps()).

4) If scheduling events from inside the ParallelSequence is necessary,
one may find helpful similar wrapper that buffers things to add and
adds them en masse after internal ParallelSequence has finished.

Regards

Maciek




On 8/9/07, Sean Luke <[log in to unmask]> wrote:
> I have given Maciej a revised version of Schedule which allows any
> arbitrary thread to query the current time() and getSteps() [read-
> only methods] but not write to the Schedule.  This satisfies Maciej
> for the moment, but it's slightly less efficient (up to two extra
> synchronizations per schedule step) which makes me Unhappy.
>
> I could go three ways here: (1) keep the Schedule as-is, (2) include
> the revised methods, which are helpful for parallel people but less
> efficient, or (3) push forward and make it possible to schedule stuff
> on the Schedule even if you don't have a lock on it.  That'd be a bit
> less efficient still, but it might be worth it in terms of
> helpfulness to parallel folks.
>
> Sean
>
> On Aug 9, 2007, at 6:42 PM, Sean Luke wrote:
>
> > The reason for this is fairly simple: the parallel sequence's step
> > call (in which you're trying to make these calls) is made from an
> > outer call to Schedule.step().  This outer call is synchronized on
> > the schedule.  However, also state.schedule.time() and
> > state.getSteps() are also synchronized on the schedule, and your
> > inner parallel sequence threads thus don't have access to it until
> > the main thread  exits from Schedule.step().
> >
> > This is clearly a stupid error in MASON's schedule: let me Ponder
> > Deeply upon it.
> >
> > Sean
> >
> > On Aug 9, 2007, at 6:27 PM, Maciej M. Latek wrote:
> >
> >> Dear MASON team,
> >>
> >> I have a number of agents being stepped by ParallelSeqence facility.
> >> For most of the time it runs smoothly. Nevertheless,  I got into a
> >> minor problem when trying to query the schedule for time: any
> >> reference to state.schedule.time() or getSteps() causes a deadlock. I
> >> have tried putting it as a synchronized call with locking on schedule
> >> and simulation, I tried adding a synchronized function to SimState
> >> that would return me that information, always with the same result.
> >>
> >> Is it possible to access schedule when agent is stepped of the
> >> ParallelSequence at all without causing deadlocks? Or is
> >> ParallelSequence locking the schedule?
> >>
> >> Above mentioned issue is more of theoretical significance for me:
> >> as I
> >> need just coarse approximation of the number of steps from
> >> schedule, I
> >> update agents with this information just before the ParallelSequence
> >> is stepped.and avoid querying the schedule. I would love to know the
> >> answer for potential future developments though.
> >>
> >> Regards
> >>
> >> Maciek
> >
>


ATOM RSS1 RSS2