MASON-INTEREST-L Archives

August 2007

MASON-INTEREST-L@LISTSERV.GMU.EDU

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

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

Print Reply
Subject:
From:
Sean Luke <[log in to unmask]>
Reply To:
MASON Multiagent Simulation Toolkit <[log in to unmask]>
Date:
Thu, 9 Aug 2007 18:42:38 -0400
Content-Type:
text/plain
Parts/Attachments:
text/plain (39 lines)
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