Re: Help on walking lists of Swarm Collection

[William S. Shu]

>Again, I totally agree with Marcus.  You should probably
>provide a funeral service in "The Almighty" (aka ModelSwarm).
>Although, in a lot of cases, the agent will need to have
>pointer to some global object (e.g. the ModelSwarm).

Thanks everyone for all the assistance, and the hints at efficiency.  I have
decided to separate (at a later date) dropDead into two messages:
    dropDead (new) -- an agent dies.  Ensure death does not adversely affect
others in the simulation.
    buryDead -- Applied during "funeral service" where agent is laid to rest
(all resources returned etc.)

This reduces the potential for conflict, but the problem still remains
(potentially) and generalises to that of concurrency at the swarm level.
For instance, one agent (e.g. a person in a personModelSwarm) grabs a
colonyList and works with it (e.g. counting the no of malaria parasites in
its colony populations) while a malaria population agent (by vertue of its
natural behaviour) dies in the malariaPopModelSwarm.  The
malariaPopModelSwarm grabs the colonyList and removes the dead agent,
possibly before the person agent has finished with it!  In computing terms,
colonyList becomes a critical resource which must be accessed only by
exactly the one agent modifying it.

The only way I see handling this (with *my* knowledge of swarm) is by
sequential scheduling of the swarms and their activities.  Any other ideas?

Are there any swarm primitives to guarantee mutual exclusion?

In general, how does one handle these concurrency issues in swarm?  What
coding style should one adopt to minimise their risks?

BTW, the addRef:withArgument: message does not guarantee this AND can only
be used in cases where an object is being droped.  from my dropDead and
buryDead situation above, addRef:withArgument will not work!

Just to make sure I understand the addRef:withArgument mechanism correctly I
give muy understanding here. (I know there has been extensive discussion on
this, but after loosing the equivalent of 5 weeks work looking for errors in
the wrong places, I cry for reassurance!  Please bear with me.)

The notify function is declared as follows.
    void
    notifyFunction (id obj, id unused, void *arg)
    {
      // obj = object notified (receiver of addRef: message)
      // arg = is argument given after withArgument:. can be any pointer
thing
      // unused = is currently unused

    ... assorted activities ...

    }



objX sends an addRef: to objY (message receiver) as follows:
     objXVariable = [objY addRef: notifyFunction withArgument: arg];

The notifyFunction is called (with objY as 1st arg) when objY is being
dropped via the drop message:

objX revokes notification by issuing:
    [objX removeRef: objXVariable];
    ... carry out any house-cleaning jobs ...

Possible application:
Should objX want to remove any pointers (id's) it holds of objY  it builds
notifyFunction as follows (with args corresponding to objX and objY):

     objXVariable = [objY addRef: notifyFunction withArgument: objX];
    ...
    void
    notifyFunction (id objY, id unused, void *arg)
    {
      // objY = receiver of addRef: message
      // arg = holds id of objX
      // unused = is currently unused

    objX = (id)arg;            // circumvent [data]-typing constraints

    ... remove occurences of objY from objX ...

    }




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