Re: [Repast-interest] Concurrency issues with GIS displays

[Logan S. <log...@gm...>]

Yes, I ended up modifying the Updater class, adding a lock to addAgents(),
removeAgents(), agentsAdded(), and agentsRemoved(). It's kind of hacked
together but I haven't had issues with it since. Thanks Nick,

-Logan S.

On Mon, May 23, 2011 at 2:37 PM, Nick Collier <nic...@ve...>wrote:

> Ah, I thought that you were doing the adding adding / removing from the
> threads in the thread pools. It doesn't look like that is the case, so
> perhaps it is in the Updater. If I remember that correctly though only the
> render code there should be in the AWT thread, all the methods that get
> called as a result of adding / removing from a context should be on the sim
> thread and there should be locks to avoid the two from conflicting. That
> said, it could certainly be a bug. I can take a look at it, but if you need
> a quick work-around perhaps you could synchronize the hashSet iteration and
> see if that helps ...
>
> Nick
>
>
> On May 23, 2011, at 3:46 PM, Logan Stromberg wrote:
>
> I'm fairly sure that the problem is independent of the thread pool I'm
> using. The code for the main method (in SimpleAgentContext.java) boils down
> to something like this:
>
> @ScheduledMethod (start=1 interval=1 priority=1)
> public void doProcess() {
>
> //Initialize threads and set them running
>
> //wait() on each thread. During this time, the individual threads will fill
> a centralized ConcurrentLinkedQueue with agents in the context that need to
> be replaced
>
> //After all threads finish processing, add and remove agents from the
> context
>    for (SimpleAgent agent : agentReplaceQueue)
>    {
>       remove(agent);
>       add(new SimpleAgent());
>    }
>    agentReplaceQueue.clear()
> }
>
> As I said, this is basically the only scheduled method in the simulation,
> which from what you're saying should be running on the main simulation
> thread.
> I noticed in the DisplayGIS.Updater.addAgents() method there's no
> synchronized code surrounding the hashset that it's iterating through, which
> is what's throwing the exception. Could that just be the bug?
>
> -Logan S.
>
> On Mon, May 23, 2011 at 7:24 AM, Nick Collier <nic...@ve...>wrote:
>
>> The issue here is that the main simulation thread is synchronized via
>> locks etc. with display updates on the AWT thread and where it is isn't ,
>> its a bug. However, if I understand you correctly, what you are doing
>> requires synchronizing display updates with your own threads and so that
>> leads to issues. Is it possible for you to do the processing in a thread
>> pool, but leave the actual adding / removing from the context to the
>> simulation thread?
>>
>> Nick
>>
>> On May 19, 2011, at 11:40 PM, Logan Stromberg wrote:
>>
>> > We're currently building a model for insurgency and terrorism using
>> Repast Simphony 2.0 beta, and there's been a lot of troubles cropping up in
>> trying to implement full concurrency in our code.
>> > The current setup is that there is a "main method", tagged with
>> "@ScheduledMethod (start=1 interval=1 priority=1)" that drives most of the
>> simulation. From there it utilizes a thread pool to do the model processing,
>> and returns from the method only after the worker threads are done.
>> > The problem is that, during the processing, agents are being
>> "neutralized" and subsequently respawned within the context (and therefore
>> being added and removed from the context in real time). The display updater
>> (it's a GIS display) apparently doesn't like when this happens during
>> rendering, because it throws this stack trace:
>> >
>> > Exception in thread "AWT-EventQueue-0"
>> java.util.ConcurrentModificationException
>> >     at java.util.HashMap$HashIterator.nextEntry(Unknown Source)
>> >     at java.util.HashMap$KeyIterator.next(Unknown Source)
>> >     at
>> repast.simphony.visualization.gis.Updater.addAgents(Updater.java:90)
>> >     at
>> repast.simphony.visualization.gis.Updater.update(Updater.java:191)
>> >     at
>> repast.simphony.visualization.gis.DisplayGIS$MyUpdater.run(DisplayGIS.java:293)
>> >     at java.awt.event.InvocationEvent.dispatch(Unknown Source)
>> >     at java.awt.EventQueue.dispatchEvent(Unknown Source)
>> >     ~~~~~~
>> >     at java.awt.EventDispatchThread.run(Unknown Source)
>> >
>> > I've tried changing the scheduler parameters for the displays between
>> FIRST, LAST, and RANDOM (apparently, even if the model code has first
>> priority and the display code has last priority, the actual updating of the
>> display runs over into the next tick, during which the model code starts
>> running again).
>> > I've tried overriding the default scheduler (by setting "Frequency" on
>> the Schedule Details panel to "ONE_TIME" and then manually calling update()
>> and render() on each display). The displays never actually rendered, but
>> they threw the exception anyway.
>> > I've tried modifying the original source code in DisplayGIS.java to
>> implement reentrant locks on the update() and render() routines (which led
>> to a lot more problems since the update code itself apparently runs
>> concurrently within the event dispatch thread).
>> > Is there any other way that I can either force the display to update at
>> a time when agents aren't being added and removed, or else receive messages
>> from the scheduler to find out exactly when the update happens, and then
>> wait() on it?
>> >
>> > -Logan Stromberg
>> > Political Science Dept.,
>> > Brigham Young University
>> >
>> ------------------------------------------------------------------------------
>> > What Every C/C++ and Fortran developer Should Know!
>> > Read this article and learn how Intel has extended the reach of its
>> > next-generation tools to help Windows* and Linux* C/C++ and Fortran
>> > developers boost performance applications - including clusters.
>> > http://p.sf.net/sfu/intel-dev2devmay
>> > _______________________________________________
>> > Repast-interest mailing list
>> > Rep...@li...
>> > https://lists.sourceforge.net/lists/listinfo/repast-interest
>>
>>
>
>