Re: [Repast-developer] Scheduler trip-up

[Miles P. <mil...@gm...>]

Just as a note, this is how I've handled in the past the similar case  
where one removes an agent and of course at that point don't want  
further behaviors executed against it. The agent (or referencing  
List, Map..) has a "delete" marker that is checked for each next..if  
set, that agent (action) is passed over. Then every iteration there  
is a delete sweep that occurs. (Actually I just rebuilt the array as  
that is much more efficient.) For array-backed lists this is  
obviously just as efficient then deleting in each case as the code  
below and you don't have to worry about  an IOOB, or in my case a  
ConcurrentModification... There is the small constant time cost, but  
unless deletions are very rare I think its worth it.

On Jul 10, 2007, at 8:44 AM, Nick Collier wrote:

> Walter,
>
> Precalculating the size of the loop is probably an example of a  
> premature optimization. The work around when removing actions is to  
> schedule the action removal for some tick time immediately after  
> the action that causes the removal.
>
> Nick
>
> On Jul 9, 2007, at 5:05 PM, Beyeler, Walter E wrote:
>
>> My application makes heavy use of the Schedule.removeAction  
>> method.  I am regularly getting an array index out of bounds  
>> exception due to an attempt to get at a missing array element:
>>
>> Exception in thread "Thread-2"  
>> java.lang.IndexOutOfBoundsException: Index: 1, Size: 1
>>         at java.util.ArrayList.RangeCheck(ArrayList.java:546)
>>         at java.util.ArrayList.get(ArrayList.java:321)
>>         at uchicago.src.sim.engine.ScheduleGroup.execute(Unknown  
>> Source)
>>         at uchicago.src.sim.engine.RandomScheduleGroup.execute 
>> (Unknown Source)
>>         at uchicago.src.sim.engine.Schedule.execute(Unknown Source)
>>         at uchicago.src.sim.engine.BaseController$1.run(Unknown  
>> Source)
>>         at java.lang.Thread.run(Thread.java:595)
>>
>>
>> Looking at the code for ScheduleGroup.execute
>>
>>   public void execute() {
>>     for (int i = 0, n = actions.size(); i < n; i++) {
>>       ((BasicAction)actions.get(i)).execute();
>>     }
>>   }
>>
>> it seems that if the executed action happens to modify "actions"  
>> by deletion then the variable "n" will still reflect the original  
>> size and so allow a bad address.  It looks like this iteration  
>> construct, rather than one using the Iterator class, helps get  
>> around the concurrent modification exception that would otherwise  
>> occur when I try to change the schedule.  If you mean to allow  
>> schedule changes within BasicAction.execute() shouldn't the size  
>> be re-set within the loop, or some other precaution taken?
>>
>> Thanks
>>
>>  -- Walt
>>
>> --------------------------------------------------------------------- 
>> ----
>> This SF.net email is sponsored by DB2 Express
>> Download DB2 Express C - the FREE version of DB2 express and take
>> control of your XML. No limits. Just data. Click to get it now.
>> http://sourceforge.net/powerbar/db2/ 
>> _______________________________________________
>> Repast-developer mailing list
>> Rep...@li...
>> https://lists.sourceforge.net/lists/listinfo/repast-developer
>
> ---------------------------------------------------------------------- 
> ---
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/ 
> _______________________________________________
> Repast-developer mailing list
> Rep...@li...
> https://lists.sourceforge.net/lists/listinfo/repast-developer