release 0.0.0.20 and thoughts

[rdm@tad.micro.umn.edu]

Billy Tanksley:
   Yes, prediction is hard.  It is nonetheless worthwhile to do in
   most cases, and in those where it isn't you can find that out with
   95% certainty 95% of the time.  You just have to know when to stop
   :).

You're still going to have to have a dynamic mechanism underneath to
deal with that remaining 0.25% chance.  Of course, if you don't have
the hardware to implement it directly (e.g. memory map unit with page
tables), you'll have to resort to other techniques (like modifying
code on the fly).

Now, if we're going to support multiple languages, you're going to
have to do a lot of language-specific stuff to deal with prediction.
Maybe you'll have some core set of prediction mechanisms which can be
shared across languages.  Anyways, this all sounds like language
implementation rather than platform implementation.  Platform
implementation involves providing the mechanisms to deal with that
remaining 0.25% chance...  There's nothing about prediction that's
specific to any platform.

   Wouldn't it be useful to have the OS be able to tell you which
   parts are critical, and PROVE it?  That's abstraction.

You're still going to have to deal with that 0.25% chance, our your
program is going to crash with a probability of 1-0.9975^n where n is
the number of time units required to run the program.

Now, given that the OS is the platform-specific stuff to keep your
program from crashing, why would tack a proof mechanism onto the OS?
It seems to me that this should be factored out as
platform-independent code.  Put it in one of those dynamically linked
runtime systems.

Or, maybe I should be using the word "Kernel" in place of "OS", and
maybe I should use the term "OS" to include things like linkers,
interpreters, compilers, and editors?

I think I'm wasting my time trying to talk using words that haven't
been properly defined for this audience.

   Both.  Although I believe (I was only convinced on this a short
   while ago, though) that coop is the best system for the OS.

Both is going to be harder than either individually.

   Starving philosophers?  Or races?  What?

Starving philosophers is a parable:

   "Five philosophers are sitting around a circular table, eating
   "rice.  Each has his own bowl.  There are five chopsticks at the
   "table.  Each philosopher can eat only when he holds two
   "chopsticks."

Let's say that only one chopstick can be picked up at one time.  [In a
message passing system, the analogy is: only one message may be
received at a time.]

Now, the problem is to come up with some sort of agreement that
prevents any of the philosophers from starving to death.  Mechanisms
where a philosopher holds on to his chipstick(s) till he's full can
result in starvation.  This is analogous to cooperative multi-tasking,
where programs keep control of the system till they're programmed to
give it up.

Of course, in real life, philosophers tend not to be quite this
stupid.  For example, if a philosopher was sitting at a table for
several days, unable to eat because his table companions weren't
sharing properly, he'd ask (perhaps politely, perhaps angrily) to be
allowed to eat.  This is pre-emption.

Actually, I'm glossing over a number of the more interesting aspects
of this system.

Also, note that some solutions to this problem involves changing the
hardware...  For example, make six chopsticks available and let
chopsticks be passed around the table (some variants of this problem
require that the chopstick picked up on the left be put down on the
left, and the chopstick picked up on the right be put down on the
right).  Then, require that after holding the chopsticks for fifteen
minutes, the holder must pass them around to his left (thus inspiring
the token ring)...  Of course, the problem here is that it leave less
time for philosophy -- so maybe only two chopsticks under this
scheme...

Anyways, maybe I should have said that this is a series of interesting
thought exercises, rather than a parable.


A race condition is where the result of a computation depends on when
the computation occurred.  A bad race condition is one that is
undesirable.  For example, consider a file system that only worked
properly 99.75% of the time -- that remaining 0.25% is going to have
to be dealt with somehow.

-- 
Raul