CELLS!

Mike Prince mprince@crl.com
Tue, 20 Dec 1994 16:49:30 -0800 (PST)



On Tue, 20 Dec 1994, Dr. J. Van Sckalkwyk (external) wrote:

> MAIN GOAL:
> ==========
> A world-wide (distributed) environment composed of
> interacting cells. If cell A migrates from machine X to 
> dissimilar machine Y, it presents similar external 
> characteristics in terms of its interaction with other
> cells, despite the move

Exactly what I'm thinking =)

>, OR, if its interactive 
> characteristics are slowed / otherwise perturbed 
> beyond a certain point, (ideally this is predicted at/before
> migration time) then it signals that it can't work!

I'm more for the kernel measuring system utilization and resources and 
moving cells around.

> (IDEA: it retains the address of its parent, and directs
> you to "try my dad, he's stronger than me, and has other
> children too")!!

Although we may do this, the really low-level stuff wouldn't have this 
feature (in my vision at least).

> We are faced with several options:
[snip]
> complex our re-coding becomes on migration. We
> should therefore try and move the transition
> point as far to the left as we can.

Agreed.

> Goal Statement: Goal #1.
> ------------------------
> To define **NECESSARY** and **SUFFICIENT**
> fundamental (primitive) cellular processes
> that can be implemented on all of the machines on
> which we _wish_ to implement our system.

Agreed. But I think the process will be more of an informal throw in 
valid thoughts as they come along.  Not because I want it this way, but 
because it's the reality of an informal group.  We can help ourselves by 
drafting a standard plus a clear description of what we're trying to do, 
and then posting them to the dozen or so relevant Usenet newsgroups.  
That would generate plenty of feedback from knowledgable people.

If we promise to remain flexible over the next 6 months about our design, 
than I think we'll come up with something good.  All too often the goal 
is to get SOMETHING working to solve THIS problem.  If we approach it 
with a "we'll keep rewriting until it's right" attitude, we stand a good 
chance of succeeding.

> Goal Statement : Goal #2.
> -------------------------
> At the same time as Goal #1 is being (we hope)
> attacked, we should establish a high level
> initiative. This should be directed at:
> 
> 2.1. Defining desirable cellular properties.
> 2.2. Defining cellular interaction mechanisms.

I'd like to think of most of a cells exhibited properties as being 
independent of the base OS.  What we'd end up having is different species 
of cells, each being able to interact amongst itself.  This would allow 
the system to "evolve" while still maintaining backwards compatability.
I can be more specific if you like about the foundation 
capabilities/characteristics of cells if you'd like.

So what I'm saying is 2.1 and 2.2 will come after our foundation OS is 
established.  (although we'll all be thinking about these a lot before 
then :)

> Suggested questions to ask:
> ---------------------------
> 
> 1. Is a cell a completely independent entity 
> i.e. own stack space, own memory blocks, own
> "processor"?

A cell is code+data.  It does not have a stack or any ability to 
manipulate itself.

An agent is something that executes the cells code, or method.  An agent 
has it's own data.  So to move data from one cell to another, you have an 
agent move the data into it's own local store, transfer to the other 
cell, and have the receiving cells method pull data from the stack or 
agent data objects.

> 2. Does a cell retain a memory of past events?
> i.e. Can it be altered?

A cell can use it's memory for anything, but I don't get the nature of 
your past events.

A cell can absolutely be altered.  But it must alter itself.  A cell may 
have a method saying take datablock x and integrate it into my method.  
So to modify that cell, you give an agent the new data and send it in.  
This has very good security (I think), because to prevent a cell from 
being altered, you simply don't put that code in.  You can also have 
security features, for instance the cell's method checks an incoming 
agent for a key, which if not found, results in it being kicked out.

Even better, the cell would report the agent to the kernel as a security 
violation.  A simple JUMP KERNEL_POLICE would be all that's needed!  The 
agent would turn itself in!

> 3. If (2) is true, would it be a good idea for
> the cell to undergo "binary fission" before
> (one copy) is altered?

Now we're having fun.  Cells should replicate themselves.  The only 
person who knows whether the data and method can be simply copied, or 
whether a more complex transformation should take place (i.e renaming the 
new cell, splitting the old data between the old and the new, certain 
data set that should stay together, immutable cells) is the cell itself.

Time to start studying meiosis again.

> 4. Can cells share common code / processes?

This is where I draw the line.  I say no about common code and data, 
thta's the whole point of encapsulating them in a cell.  A process on the 
other hand (my agent) jumps eveywhere to accomplish the execution of methods.

> 5. How does cell death occur - eg. suicide
> messages? Who has control over this? Do/Can 
> copies of a cell "inherit" the parent's death?

A cell is a complete organism.  It can kill itself, with one simple 
instruction actually.  An outsider can ask it to kill itself using the 
previously mentioned agent to pass a message.  Or the kernel of course 
can say enough is enough.

The kernel issue is one we should talk about a lot.

> 6. How does cell birth occur?

As per the above, mitosis, a cell gives up data that creates another cell.

> Should a cell 
> have a unique "birth certificate number", and
> if so, is it desirable to / how can we
> keep track of cell birth worldwide.

When a cell is first created the only one who knows about it is the 
kernel of the locale and (maybe) the cell who spawned it.  To get an 
address the cell "registers" a name for itself.  In my current version 
the name is between 1 and 127 bytes long.  This name follows it during 
migration.  See next about tracking... 

> Might it
> be a good idea to have "local registries"
> allocating "birth numbers"

I was previously advocating a level between Global and Locale of Domain.  
Each domain has a directory (or algorithm) for directing calls to named 
cells.  Each locale has a similar local directory.  I haven't settled on 
a Global system yet; probably as a cell name search fails a domain would 
send it off to some friendly global server.

NOTE:  I've also played with the idea of having flags to limit the scope 
of cells and agents; either to locale, domain, or global (no bounds).  
These flags, again are set by the method for each cell, and are changable.

> and even perhaps
> keeping a register of "cellular properties"
> eg "This is a word processing cell..."??

One of the higher level functions a family of cells might have, is to 
report capabilities.  You send an agent to a standard "port" of a known 
cell name and the capabilities, some help info, an icon, etc might be 
returned.  Your local system might catalog these for future use.  But I'd 
like to keep these above the foundation OS.

> 7. How can we define mechanisms of cellular
> interaction?

The agent is the fundamental mechanism (the OS provides blocking 
semaphores to synchronize agents).

> Data streams between cells?

Implemented using agents to send events of data.

> When should synchronisation be used? How?

See above.

> 8. If a cell is about to migrate / has
> migrated, how can its performance be
> assessed? When should it "soldier on"
> despite being fairly ineffectual, and
> when should it quit? Should the criteria
> for "quitting" be internal or EXTERNAL?

I think it should be external to the cell, and in the OS.  An important 
policy to remember is to seperate policy from mechanisn.  The OS has the 
mechanism, though I suspect it will ask a higher level about policy.

> 9. On a particular machine, with limited
> resorces, and several cells running and
> straining those resources, should a
> particular allocation strategy be used
> to dispose of those resources. Should we
> use some sort of "Banker's algorithm" or
> what? What preventive / rollback mechanisms
> should be in force? Should different cells
> have different priorities, and if so,
> how should these be enforced.

There are lots of factors and ways to do optimizations.  The important 
thing to remember is to have the OS able to collect enough information to 
do it properly.  Again, we must initialy focus on mechanism and efficient 
information gathering for our policy makers.

> 10. In a group of interacting cells on
> different machines, should we apply the
> considerations mentioned in (9) above,
> especially with migration occurring..?

See above.

> Just trying to give things a little form.
> At present, Mike seems to be the only one
> of us with some direction!

Thank you!

> Bye, JVS.

I am very pleased to see that others can see viable alternative ways of 
doing things.  I hope this bio/life oriented approach will be fruitful =)

Mike