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