Re: Simulation frameworks in C++?

[Christoph Schlumpf]

Dear Manor,

>> I'm still curious about the possibilities of using threads as an
>> alternative to schedules or while loops. Yet another topic, I guess.
>
>It may be the case that most schedules will be quite simple, and require
>only one or two locks, but I really believe that in principle this is a
>very hard thing to do, certainly its difficult for non-comp-sci people.
>
>However, there is a compromise in the air, i.e. express the actions in a
>centralised data structure a la schedules, but thread its execution (where
>this is allowed). Such an approach would have the benefit of clarity, and
>explicit representation, but also has presumably a large run-time benefit.

I think this is the way to go. Many actions have to be executed one after
another. There, the schedules are the right thing at hand. To do concurrent
programming I too think that the use of a scedule which then does the
threading makes things easiest for swarm users. I see three problems
concerning threads in a java swarm.

First the simulation agents have to be made thread secure. While java
offers all structures needed to make thredsafe classes it is quite
demanding for a non professional programmer to implement a threadsafe
class.

Second, multithreaded simulations could be much slower in execution on
single processor machines than single threaded simulations. I don't think
this is a great problem but as we think on performance issues concerning
java i wanted to mention it. The more processors the more advantage the
multithreaded simulation will have over a singlethreaded simulation.

Third, in the current implementation of swarm which is as far as I know
singlethreaded, the schedule doesent have to bother if the execution of an
action is finished. The schedule may only invoke the next action when the
former action is finished. In a multithreaded language, swarm users could
start new threads at any given time in the simulation. So the schedule
doesen't know that all subsequent threads are finished when the original
action thread it started has finished. Java allows for testing if threads
have finished and Java allows for grouping, stopping and invoking of
threadgroups. These mechanisms could be used to make threadsave swarms. I
think to introduce threads in schedules poses some difficult design
questions. The advantage out of multithreaded swarms are obvious to me but
I'm not sure how easy it would be to implement threads in swarm.

>BTW... I think that thanks to the Garbage Collection that comes with Java,
>the developpers will be able to spend some time looking into this (which
>is currently spent looking at stuff like memory leaks and so forth)! After
>all, theoretically this approach is feasible in ObjC-Swarm, its just that
>the language is full of other details one has to worry about...
>

Memory leaks are one thing which could be solved in a Garbage Collecting
language like java. Thinking on really big swarms (with dozends to hundreds
of Agents classes and thousands to millions of agents) the Java-typesafety
system could help to make reliable simulations. Java offers a lot of
exception handling structures which could help debuging and running large
simulations.

yours,
Cristoph