Event and Process [Was: Re: more help please]

[Sven N. Thommesen]

I'll take a stab, too, from a different angle than Alex and Jan:

At 01:12 AM 7/16/98 +0100, Laurence wrote:
>Hi all,
>
>First of all, many thanks to everyone who responded to my last questions.
>Since then I have been able to extend my SWARM chemotaxis model so that the
>objects representing the enzymes are represented in their correct
>concentrations.  I have further queries however about SWARM's parallel
>execution.
>
>Basically, the input into the system takes the form of a message to each of
>the 500 receptor objects.  The signals then pass through a network of
>interconnected enzyme objects, some of which work antagonistically, to the
>single motor object, whereupon the signal will affect the motor's state.
>
>Q1: The enzymes that work antagonistically seem to be waiting for a method
>to finish instead of interrupting that method by calling it again with a
>different value as a parameter (so as to change a flag).  Can an object
>execute the same method more than once at a time?  If not, how can the
>execution of methods be interrupted?

You question about interrupting executing methods leads me to remark as
follows: there's a difference between simulators or simulation languages
that implement a pure event model (such as Swarm) and those that implement
a mixed event/process model (such as ModSim-III from CACI, see
<http://www.caciasl.com>). In Modsim, in addition to the usual methods
which execute till completion before returning some value, there called
'ASK' methods, there are methods called 'TELL' methods which do not return
any values, and which return control to the caller immediately. Then the
called method executes (in principle, at least) in parallell, in the
background.

So, for example, an airplane object may be sent the message
TELL myAirPlane TO FlyTo: NewYork.
The object then calculates how long that will take, and it executes a
'WAIT' for the required amount of simulation time. During the wait, the
state of the object is that it is executing the FlyTo: method. It can be
interrupted during flight; TELL methods usually are written with a code
section that deals with interruptions.

ModSim is its own language, which is pre-processed down to C++ during
compilation. So there are 'magic' calls to the scheduler etc. done behind
the scenes.

In Swarm, to achieve similar results, a FlyTo: method would have to
calculate for how long to fly, then ask the scheduler to have an EndFlyTo:
message sent to itself at the appropriate time, then return to the caller.
In the mean time (until called with EndFlyTo:), it would just need to keep
an internal record that its current status is 'flying somewhere'.

(Hope this was relevant and/or interesting ...)

>Q2: I have a BLT graph monitoring the state of the motor (represented as an
>int, range 0-4).  However, the messages sent to the receptors trigger 1000s
>of other messages, some of which affect the motor state.  Instead of showing
>this, the graph waits until every message has been sent before continuing,
>displaying only the motor's final state after many fluctuations.  How can I
>get to graph to keep going whilst other messages are being sent?
>

There's code buried somewhere (I'm not sure exactly where in 1.2, but it's
there) to update the graphs once per time period. Either schedule more than
one such call per time period [--if that's possible, Marcus?] or make your
simulation time more fine-grained so that the once-per-period graph update
is often enough.

>Both these problems involve parallel execution, which I thought SWARM was
>capable of.  Why should this happen?
>
>Best wishes, Laurence (address@hidden)

Cheers,
Sven


                  ==================================
   Swarm-Support is for discussion of the technical details of the day
   to day usage of Swarm.  For list administration needs (esp.
   [un]subscribing), please send a message to <address@hidden>
   with "help" in the body of the message.
                  ==================================