In response to the questions below.

1. Yes, it's doable -- but you have to lock *somewhere*.  If you  
don't do a global lock with MASON, you're going to have to do some  
fine-grained lock on some subelement of MASON to make certain that  
MASON Steppables aren't scribbling at the same time that the repaint  
method is reading.  Otherwise you're going to have a race condition.

2. It won't violate any MASON design principle.  But there are two  
things to keep in consideration:
	A. You need to gather the repaint thread at some point, when the  
simulation is stopped.  AsynchronousSteppable would do this; else  
you'll need to roll your own approach.
	B. Fine-grained locking means a lot more synchronized{ } calls,  
which can be expensive.  Having a global lock on MASON to paint, then  
to do the model, allows MASON to largely run unsynchronized (except  
for the schedule, sigh).

3. Essentially no modification.  I think the easiest way to do this  
is to copy the network first, and then you don't have to do any  
locking!  You can do the copy in a Steppable stored in the GUIState's  
minischedule, and then fire off something to do drawing on the *copy*  
of the network in the background.  Though you need to check to see  
that your GUI can accept a new copy -- it's done drawing its old copy  
-- before you shove a new one at it!

Sean


On Oct 10, 2006, at 12:48 PM, Maciej M. Latek wrote:

> OK, now I see a clouded path to follow: use Asynchronous Steppable  
> just for
> a certain time-consuming display and leave the rest GUI unchanged.
>
> Maciek
>
>
>
> -----Original Message-----
> From: Maciej M. Latek [mailto:[log in to unmask]]
> Sent: Tuesday, October 10, 2006 12:31 PM
> To: 'MASON Multiagent Simulation Toolkit'
> Subject: Make things more parallel
>
> Hi all,
>
> I've got a question concerning parallelization of visualization  
> inspired by
> parallel version of Heatbugs (which works very nicely on a Core Duo  
> by the
> way, one can really see the difference) and Mr. Ong's problem.
>
> My understanding is that, as the GUI thread repaints displays, the  
> SimState
> thread is put on hold. When we consider really computationally  
> expensive GUI
> tasks as laying out a graphs, this seems to be suboptimal solution.  
> I was
> wondering if it would be possible to put the two thread on separate
> processors, have the GUI thread probe the other one for information  
> and
> afterwards to detach and free the SimState thread to go ahead while  
> GUI is
> doing its job. After GUI is done, the process would repeat.
>
> I realize that in general I would loose synchronization, but if I'm  
> laying
> something out let's say each 50 time-steps and still have to wait  
> few second
> for the simulation to resume, this path would provide me with much  
> smoother
> and faster performance.
>
> The questions are:
>
> 1) Is it doable?
> 2) Would it violate some important MASON design principle?
> 3) How much modification to MASON core would one have to introduce  
> to arrive
> at such a solution?
>
> Regards
>
> Maciek Latek
>
>
>
>