A Summary of Project so far [Re: Kernel LISP - how low down can it go?]

[Henry G. Baker]

> CMU-CL does not have threads - so we are free to roll
> our own how we wish.

> The LispOS: will use a single logical address space, will (eventually)
> be Lisp-to-the-metal, is generally defined as a completely reflective
> object-oriented multi-threaded OS with garbage collection fundamentally
> built-in, and will have an object-based file system (there is much
> contention about how far this should go - for myself, just a plain old
> OOFS, even without true transparency, would make me very happy, but I
> have no axes to grind on this topic).

I have noted elsewhere that the problems of synchronization of threads
and OODB synchronization and recovery are all quite similar.  In the
case of OODB's, you have multiple users trying to access the same
objects.  If the objects are functional, then they can be shared without
any restrictions, while if they are mutable, then each user is building
up a different view of what the OODB looks like.  At commit time, the
multiple users lay their cards on the table, and the winner gets to
commit, while the losers have to roll back.  Recovery is _exactly_ the
same, except that in this case the process you are competing with is
the recovery process itself.  From time to time (i.e., when the system
crashes) the recovery process wakes up and wins the hand, and forces
everyone else to roll back.

With multiple threads, you still need some form of high-speed
synchronization.  Rather than use a totally different model, you end
up with threads 'nested' within an outermost process that is the
user's access to the OODB.  But even within the machine (i.e., outside
the OODB), one will still have commits, aborts and rollbacks.  In the
case of spinlocks, the commits, aborts and rollbacks are all trivial.

----

The amazing thing about Lisp & OS is that while we think we have a
pretty good handle on _memory_ management (i.e., GC), we don't seem to
have a very good handle on _time_ management.  What is the equivalent of
'bounds checking' for time slots?  What process allocates time and
reallocates it at the end of the time slot?

If you plot critical sections wrt to processes and time, you find a
kind of a vortex or a knot in the topology.  Perhaps there is an
insight there that can be used to simplify our thinking about these
problems.

I realize that this is pretty researchy, but every successful _new_
system has some small degree of innovation.  I hope that much of LispOS
innovation is of the form "cut away the fat, cut away the bandaids and
the chicken wire", rather than creating new levels of bandaids.

---

Those of you who aren't familiar with Rodney Brooks's 'subsumption'
(layered) architectures for mobile robots should have a look.

ftp://publications.mit.edu/ai-publications/500-999/AIM-864.ps

Don't take his suggestions too literally, but do allow the ideas to
percolate in your head.

-- 
Henry Baker
www/ftp directory URL:
ftp://ftp.netcom.com/pub/hb/hbaker/home.html