[kepler-dev] web service actor

Edward A Lee eal at eecs.berkeley.edu
Thu Apr 1 07:16:32 PST 2004


At 02:18 AM 4/1/2004 -0800, Bertram Ludaescher wrote:
>Apropos breaking the model of computation: I'm not sure whether I
>asked that before, but what are the "recommended" (and maybe not so
>recommended) means to "drain" a running process network.
>
>Clearly a PN is easy to "drain" or "starve" from the "head", i.e.,
>source side, by slowing down or stopping token production.
>
>For some applications it may be desirable to also slow down or even
>stop the computation at an arbitrary point downstream.  I've heard of
>this notion of "backpressure" that can be applied in the opposite
>direction of the token flow to slow down (and possibly pause/stop) a
>process pipeline.
>
>Is such a thing already in Ptolemy II?

This is a deep question.

The Ph.D. Thesis of Tom Parks addresses much of this,
and gives the principles behind the way Pt II schedules PN
models.  It's at:

http://ptolemy.eecs.berkeley.edu/publications/papers/95/parksThesis/

The bottom line is:

- almost anything you ask about a process network is undecidable.
- Determining whether particular actors are "starved" by any
   given action is tantamount to solving the halting problem...
- lots of schemes exist in the literature for "demand-driven",
   "data-driven" and "fair" execution.  They are all "wrong" in
   that it's easy to construct models where their execution is
   clearly not what you want.
- The question of whether the execution policy is "right" can
   be posed as determining whether a finite execution is
   an approximation to the infinite denotational semantics.
   Comparing schemes amounts to determining how to define
   "approximation" and how to define progress towards the
   (unachievable) infinite behavior.

Edward



------------
Edward A. Lee, Professor
518 Cory Hall, UC Berkeley, Berkeley, CA 94720
phone: 510-642-0455, fax: 510-642-2739
eal at eecs.Berkeley.EDU, http://ptolemy.eecs.berkeley.edu/~eal




More information about the Kepler-dev mailing list