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