Re: rescheduling

[William S. Shu]

>Thanks for the sample code, Marcus, it'll be very useful!
>Possibly this code can be re-packaged into general utility
>methods like:
>
>   [ ActivityToolkit remove: Future actionsOn: schedule
>                        for: target                     ];
>
>where `Future' is Symbolic short-hand for specifying the use
>of the `time > getCurrentTime()' filtering function.  Other
>related functions could be: `get:actionsOn:For:' and
>`retarget:actionOn:For:To:' and etc.  What do you think?
>(I suppose these would be just wrappers for basic methods in
>a "CollectionsToolkit", eh? =:-)


I agree with Ken that code such as the above should be packaged for easy
se  -- The code from Marcus seems a bit complicated.  In fact, I have been
faced with this and related problems, and was hoping to bring it up only
when I had successfully grappled with other more pressing issues of swarm --
mainly learning.  I hope we can have extensive discussion/clarifications
over the issues raised below.

It seems one must necessarily face the type of problem faced by Ken once
there is a hierarchy of swarms or when an object is variously (randomly?)
treated as a "Swarm" or a "SwarmObject".

A Suggestion: it seems one can actually define the number of simulation
(time) steps in a Batch swarm run.  Can this not be modified so that one can
dynamically change the number of simulation steps (for selected swarms) to
zero, even for interactive swarms?


Another problem is that the precise meaning (semantics) of scheduling and
swarm-level operations is not evident (perhaps a documentation problem?) and
so one is quickly at a loss when faced with concurrency issues (at
implementation level, not simulation).  Perhaps this could be put in the
form of questions:
a)     How does one "break into" the scheduling cycle of a given swarm, and
possibly reorganises it and ... gets away with it?
b)      When an object is dropped, in which scheduling time-step are other
objects (possibly in different swarms) notified?


Related to this, the addRef:withArgument: method may need to be more clearly
defined, as one inevitably runs into the equivalents of low-level
concurrency issues (signals, semaphores, locks, ...). For instance, for the
        [targetObject addRef: notifyFunction withArgument: obj];
method, it may be nice to know what happens if this method is applied more
than once, possibly with different 'notifyFunction's, and how corresponding
'removeRef:' will behave.

Intuitively, one may simply say "respond only to the first of multiple calls
of an addRef:withArgument: message, and ignore all but the first of the
matching removeRef: messages".  But this would not necessarily do, if these
messages where used to synchronise *specific* code fragments, or mutually
exclude entry into them.


Still on the addRef:withArgument: message, notification is done everytime an
object changes.  This probably causes high runtime overheads.  Furthermore,
it is completely up to the programmer to determine (within notifyFunction)
which changes are worth responding to.  This could be error-prone,
especially as concurrency issues have to be reasoned out carefully.

A Request:  Is it possible to modify addRef:withArgument: (or provide
alternative messages) to respond to specific classes of changes? e.g., just
before an object is dropped, when a lock (mutual exclusion) is desired, or
when a certain event occurs.  (NOTE: I am not advocating for an operating
system to be built into swarm!)


Thanks

William.



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