Re: Help on walking lists of Swarm Collection

[Jan Kreft]

Hi,

I guess it would help if death isn't instantaneous, don't let the agents
die immediately, instead, put them in a waiting list and clear the list
after all agents have performed their step activities. Or maybe more
efficiently, recycle the dead, make a recycle list and use one member from
the list instead of creating a new one from scratch, just reinitialize all
settings.

Examples of that can be found in Gecko (hook is an ivar of type id):

-recycle
{
    [species tallyDeath: self];

    hook = recycleBacilluss;
    recycleBacilluss = self;
    [species decrementCensus];
    return nil;
}

-recycleClear
{
    Bacillus* togo;
    while (recycleBacilluss) {
        togo = recycleBacilluss;
        recycleBacilluss = recycleBacilluss->hook;
        [togo drop];
    }
    return self;
}

-reuse
{
    Bacillus* result = recycleBacilluss;
    recycleBacilluss = recycleBacilluss->hook;
    result->hook    = nil;
    return result;
}

+create 
{
    id result;

    if (recycleBacilluss) {
        result = [recycleBacilluss reuse];
    } else {
        result = [Bacillus createBegin: globalZone];
    }
    return result;                                      
}

Hope that helps, Jan.

Jan Kreft                               Phone +44 (0)1222 876036
Cardiff School of Biosciences           Fax   +44 (0)1222 874305
Cardiff University                      E-mail address@hidden
PO Box 915, Cardiff CF1 3TL, UK

On Tue, 11 May 1999, William S. Shu wrote:

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


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