swarm-support
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: more help please


From: Alex Lancaster
Subject: Re: more help please
Date: 15 Jul 1998 18:51:33 -0600

>>>>> "L" == Laurence  <address@hidden> writes:

A couple of addenda to my previous message.  

L> Hi all, First of all, many thanks to everyone who responded to my
L> last questions.  Since then I have been able to extend my SWARM
L> chemotaxis model so that the objects representing the enzymes are
L> represented in their correct concentrations.  I have further
L> queries however about SWARM's parallel execution.

L> Basically, the input into the system takes the form of a message to
L> each of the 500 receptor objects.  The signals then pass through a
L> network of interconnected enzyme objects, some of which work
L> antagonistically, to the single motor object, whereupon the signal
L> will affect the motor's state.

L> Q1: The enzymes that work antagonistically seem to be waiting for a
L> method to finish instead of interrupting that method by calling it
L> again with a different value as a parameter (so as to change a
L> flag).  Can an object execute the same method more than once at a
L> time?  If not, how can the execution of methods be interrupted?

No.  Methods always run to completion in the current Swarm, otherwise
you would have contention problems when updating the instance
variables.  So Swarm objects are not thread-safe.

A workaround to `faking' the parallelism as is were, maybe to have
some fixed `integration' period in which your enzymes objects monitor
the messages being sent to them, then based on the cumulative activity
of these messages change their state according to some algorithm.
There's simply no direct way to do what you are suggesting with
current Swarm activity structure.  Maybe Roger will have more to say
on this matter - and probably correct me ;-)

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

The basic way to solve your problem currently is to run in batch-mode
and collect data to a file for display at the end of the run.  It's
not a perfect solution, I know, but the best we can offer right now.

At the moment the `GUI' schedules and `model' schedules in Swarm are
completely intertwined - they are one thread of execution in a single
binary.  Decoupling these into a Swarm `viewer' and Swarm `model'
which could communicate asynchronously is also on the development
agenda for the future.

If you are displaying Rasters there are a couple of BatchRaster
classes offered on the user community page, that allow the
`snapshoting' of runs whilst running in batch mode, and the playback
at the end of the run.  We are aiming for this to be incorporated into
Swarm proper in 1.3.

Regards,
 
  --- Alex

-- 
  Alex Lancaster         |   e-mail: address@hidden
  Swarm Developer        |      web: http://www.santafe.edu/~alex
  Santa Fe Institute     |      tel: +1-(505) 984-8800 (ext 242)
------------------------------------------------------------------

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]