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
>