swarm-modeling
[Top][All Lists]
Advanced

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

Re: parallelism


From: glen e. p. ropella
Subject: Re: parallelism
Date: Thu, 30 Mar 2000 07:51:18 -0800

At 11:12 AM 3/30/00 +0200, you wrote:
>   1) Require that setter methods (instead of "=" assignments) be used
>      to keep probing mechanisms in-sync.
>
>      + easy to implement
>      - requires programmer vigilance

This could be automated, so no vigilance needed, but I keep having in
mind that different languages are likewise more/less suited for that.
(change the preprocessor)

Well, vigilance is needed in the sense that if you continue
to use Java or ObjC, you have to either rigorously *prevent*
the user from using assignment statements (and other things
like increment/decrement and bit-shifting).  This would require
one hell of a preprocessor.  So, it's not feasible to automate
in some languages without changing how the programmer programs.

So I'm not sure, you're talking Obj-C or Java Swarm?

Either/both.  We already have the concept of getter/setter
methods, which, if the programmer cooperates, isolate assignment.
I.e. never do "x = 6;"  always do "this.setX(6);"  With that
convention, or with the probing convention, we could instrument
the getter/setter methods or probes to record every transaction.

  Anyway, could it be
helped by proposing the use of @private ?

Could help; but, even with private variables, you can still
use assignment (and increments etc.) within the same object,
which would change state underneath the logger.

>   3) Don't worry, be happy: make methods opqaue to probing, requiring
>      modelers to do more fine-grained scheduling in order to expose
>      state changes.

I still don't get this fully, you mean scheduling on the algorithmic
level, or is there an example for fine-grained scheduling?
Isn't this called iterators?

This just means making every transaction go through the scheduler.
So, we wouldn't let the programmer do things like:

   [bob setX: 6];

We would always do things like:

   [myActivity executeThisAction: M(setX:) : 6 withConstraint: time.soon];

Or somesuch.

>      + clear logging semantics
>      - methods are opaque

I'm not sure what you mean by this, is there any literature on that?

I doubt there's literature on this explicitly.  But, if you
check out some of the tracing literature, including algorithm
animation and profiling, you'll find full explanations.  Basically,
what Marcus means is that, if we don't have instrumentation around
all state changes (including method and function calls), then
we would have to muck with the compiler (or the preprocessor, if
there is one) in order to create a well-defined approach to
logging.

So, basically, we can either go *up* and put an extra layer
between the programmer and the machine, or we can go *down*
and futz with the compilation/translation machinery.  But,
if we don't do one or the other, what we log and when we
log it will be ad-hoc at best.

glen

--
glen e. p. ropella =><= The front line is everywhere. Hail Eris!
Home: http://forager.swarm.com/~gepr              (505) 424-0448
Work: http://www.swarm.com                        (505) 995-0818


                 ==================================
  Swarm-Modelling is for discussion of Simulation and Modelling techniques
  esp. using 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]