HLL Process Model

[Jecel Mattos de Assumpcao Jr.]

On Sat, 11 Mar 1995 09:30:30 -0800 (PST) Chris Harris wrote:
> I think with what we're trying to do with TUNES, any programs/objects 
> that are "dusty decks" will be rejected by the TUNES community.  Once we 
> get people used to the benefits of small, interacting objects over huge 
> programs, I doubt they'll want to switch back.  So most programs will 
> have to be rewritten, but doing so will be a great advantage.

Indeed! I was just explaining why the obvious object=process model
isn't explored more. We want to write new programs and don't have
a high opinion of existing ones, but many other people don't think
that way. I understand them, even if I don't agree.

> I like the process communication model used by Clouds.  Basically, each 
> process has a small internal stack, and runs around executing different 
> objects (basically C-like code with some entry points), modifying their 
> variables, etc.. 

Here you have explicit processes operating on passive objects. An
interesting model ( Smalltalk, Self, etc.. use it ) but it is very
different from what we were proposing.

>  If you want to have IPC, you simply have two processes 
> access the same object, and share its variables.  If you had the get/set 
> variable methods be tied in with semaphore or such, you could make some 
> really clean code.  (With a well-set-up object, you could just tell it to 
> access variable j of object o, and if it wasn't availible at the moment, 
> it would put your process to sleep.  That way, you don't have the sync 
> code mucking around with your program flow.)

This is how William Dally's ( MIT ) Concurrent Smalltalk does it
( there is also a Concurrent Smalltalk from Keio University that
*does* use the Actor model - don't confuse the two ). It gives
the programmer much more control, but makes things more complex
for people with no experience with parallel systems.

> Who said TUNES was going to be easy?  =)  I think the key is to design 
> models with enough expansion capability to one day reach this level of 
> complication.  Doesn't mean it'll be this neat from day one.  Just that 
> it has the potential to be made that way.

That's the spirit! Just be careful not to put in things you don't fully
understand or they'll come back to bite you later...

> > There is a missing element here - cell sharing. Can you use a cell
> > as a sub-cell of two different higher level cells? If you can, you
> > will have to find a way to deal with multiple "instances" of a cell.
> 
> I would vote no.  I'm for a prototype/delegate object model, as described 
> in the SELF stuff.  That way, you create objects by cloning existing ones 
> and if you pass an object a message it doesn't understand, it will fire 
> it off to its delegate.  They describe how to make whole class hiarchies 
> this way....

You don't have to convince me - I program a lot in Self and love it!
But even in Self you have to dynamically clone method objects to
create activation frames or the thing simply wouldn't run. The
prototype/instance issue won't go away no matter what you do. But
you can choose where it will happen.

> Actually, we may not even need to support delegates.  Perhaps we just 
> support cloning of objects, and then if an object needs a delegate (when 
> it receives a message it doesn't understand), it can fire it off to an 
> object of its choice.  That would reduce the overhead on the system level....

True. Look at the Self variant called Moostrap, which can be found
from the Tunes pages, I think.

> > [ stupid factorial example - how to do it with cells? ]
> 
> Have to get back on that one.  (Have to drag out the ol' C book and 
> remember what some of this stuff means.  hehe...)  The problem with such 
> an example is where do I define the primitives?  What if I make a fact 
> primitive, and so it only requires one cell?  =)

Don't worry about, I just wanted to see *how* cells were nested in
each other. I wondered if a cell could be a subcell of itself, for
example. If fact were a primitive, I would have to think up a better
example. All this assumed your cells were a kind of data flow thing.
If they are really objects, then none of what I have written makes
any sense.

> > If you do object composition by "enclosing", how do you share things?
> > Or am I missing something here?
> 
> I think I'm speaking mainly of physical storage here, not so much logical 
> objects.  It might be applied to logical objects too, although it might 
> take some thinking.  This is an issue, although I'm not sure how it 
> works.  I guess we could use the generic "proceeses don't exist; we don't 
> need sharing" argument.  =)

I thought that you were proposing that if cell A "encloses" cells B and
C that we would have this in storage:

        A's mem space --------------------------
                                              |  B's mem space --------
                       |                  \-----
                       |  C's mem space --------
                       |                  \-----
                       \------------------------

If this was the case, it would be hard for B to also be inside cell X.

> > I have done so in Merlin: one object = one process ( except when
> > they are not :-). This model is close to the real world where each
> > component works in parallel with all of the rest. I have to allow
> > some exceptions for performance ( immutable objects can have many
> > processes ) and for compatibility with sequential code ( recursion
> > would always deadlock otherwise ).
> 
> I don't think this is a very useful way to represent things.  Because 
> depending on what you're representing, you're always going to want more 
> or less processes per objects.  I would again like to follow Fare's 
> notion: processes don't exist, only active objects.  How that works, I do 
> not know.

Imagine the active object 3. If it executes its messages one at a time,
not only is performance going to be terrible in a multiprocessor system
but a simple thing as "3 * ( 3 + a )" might deadlock! On the other hand,
if an object such as a simple counter can receive several message at
the same time we might have an inconsistent execution. Fare has already
pointed out a few solutions to this. My problem is not finding solutions,
but sollutions that are as simple and understandable as possible.

-- Jecel