arrow-structure syntax and semantics

[zccap74]

Just collecting my thoughts.....

Brian:
>        -'data-flow graph' could be better explained as 'symbol flow graph'
>(or structure flow graph).  the point is that the arrow-structure in
>question migrates to the location where it is used, instead of having a
>representation.  maybe this concept won't work.

I think it will, you can draw analogies to thread systems:
>Such distributed threads most naturally lead to passive object style
programming models, as in Alpha; but they can be effectively employed in
>procedural models also.
>
>A distributed thread is the schedulable execution entity. It is a sequential
flow of execution through code in passive objects. It has 
>
>       a unique identity 
>       attributes -- e.g., relating to such properties as 
>              timeliness 
>              importance 
>              synchronization.
>
>A distributed thread's single point of execution, identity, and attributes
are maintained across address space and node boundaries, even in the
>presence of failures.
>
>A distributed thread is independent of any specific object. Distributed
threads execute in asynchronous concurrency with respect to each other,
>except as controlled by synchronizers in objects.
>
>A distributed thread extends itself outward from its root -- the point at
which it was created -- an additional segment in length, by moving its
>head -- its current execution point -- via invocation of a method on the
target object. A distributed thread retracts itself one segment inward
>toward its root by returning from an invocation. 

Now admittedly your arrows are structure pointers as opposed to execution
entities (currently?) but moving the arrow structure adds a layer of
abstraction (more arrow pointers) while at the same time decreasing the layers
by associating with a location, not a representation ie. it is just changing
context, so it can work, and a lot of work has been done on migrating
threads...

It seems like the arrows representation is a good start (it solves a lot of
problems eg. type constraints etc.), however there are some things I am
worried about: you have not talked about methods of sync.  (for
distriution/parallelism, no  reference has been made to gcc (needs to be
considered along with semantics content in factoring out) or cooperative
scheduling.

Fare.
> What I mean is: there are lots of things that we don't have to reinvent,
> and that we shouldn't reinvent, because it's already there.
> I certainly do not mean to lessen any one's talent.
> But I'd rather learn known things from a book, and discover new things,
> than discover known things the hard way, and have no time for new things.

And a good page I have seen is:
http://www.realtime-os.com/progmod/progmod.html

(actually the whole of the site) It talks about the Alpha kernel and threading
through passive objects, as well as distribution.

>Alpha's most significant contributions to the state of the art -- both per se
and in terms of their influence on subsequent (albeit belated) OS kernel
>research -- included: 
>
>       a computational model specifically for time-constrained close
cooperation among arbitrarily (e.g., peer) related nodes via control flow 
>              based on a "distributed thread" abstraction which may span not
just (passive) objects but also address spaces and thus nodes 
>              with location-independent method invocation semantics -- e.g.,
each distributed thread retains its identity and attributes (including
>              end-to-end timeliness constraints and parameters) -- and
syntax, as it extends and retracts itself among objects 
>       an efficient implementation of distributed threads using a native
kernel RPC facility (i.e., not layered on a message-passing IPC
>       abstraction), which included 
>              asynchronous exception handling (e.g., time constraint
expirations) 
>              orphan detection and elimination 
>              dynamic, adaptive, thread resource management 
>       the first implementation of Jensen's 
>              utility function (nee' "time-value function") scheduling
framework, which provided for arbitrary mixtures of hard, general (soft),
>              and no completion time constraints -- even for an individual
thread 
>              "best-effort" class of scheduling policies for
application-specified graceful adaptation to dynamic uncertainties such as
overloads
>
>       and the provision for arbitrary application-specific real-time and
non-real-time scheduling policies, by employing a common set of kernel
>       mechanisms 

More when I have time...
Alexis