release 0.0.0.20 and thoughts

[Billy Tanksley]

On Thu, 17 Aug 1995 spc@gate.net wrote:

> On some network somewhere in cyberspace, Billy Tanksley transmitted:

>>>>From my point of view, it is.  If you force virtual memory on everything, 
>>>>many things will have trouble.  If you only provide virtual memory as a
>>>>service to things that need it, nothing will break.  (Simplified case.
>>>>Murphy's law may apply otherwise in some finite states.)

>>>   Care to name what virtual memory causes troubles with?  About the only
>>> argument I can think of is that under certain systems, virtual memory
>>> comsumes space for the tranlation tables (not all system have this trouble,
>>> notably those where the virtual memory is handled externally to the CPU) and
>>> are *slightly* slower than non-virtual memory systems (I'm excluding
>>> swapping out to disk here in this case).

>> Virtual memory includes swapping to disk.  That's the meaning of 
>> virtual.  If you mean memory protection...

>  Okay.  But still can you answer the question?  This time with BOTH memory
>protection AND virtual memory.

To some extent.  I'm sorry I brushed it off so lightly last time; I was 
rushing on to the next point (later on).

The point is that when you've proven exactly when a program can and can
not be virtualised, you (the OS) can make many small details faster.  
In addition, things like anticipating swap demands are much easier.

I know, this doesn't answer your question OR back up my statement, but on 
the other hand, my statement really had little to do with what we're 
actually talking about (sure some programs will crash if you swap some 
critical data structure out at the wrong time! ;).

> > Then it is clear that there is some benifit in proving such things about 
> > it, and thereby reducing the supervisory burden on the system.

> > Actually, the total amount of supervision is the same; the difference is 
> > that by proving those things about the task the system can ignore those 
> > aspects of the task during runtime.  You lose a constant amount of time 
> > at startup, you gain a linear amout of time during running.

>   Okay, that I'll buy.

It seems that we're in complete agreement, aside from some silly remarks 
I made about virtual memory being a danger in general (it's only a danger 
in specific cases).

[stuff deleted]

>   Sorry, but I didn't notice the (very) subtle shift in what you were doing.

That's OK.  I have a problem with that-- I'm either so subtle that nobody 
knows what I'm saying or I'm so offensive/redundant that no one replies to 
me :).

> > I'm saying that cooperative multitasking is more flexible than preemptive 
> > multitasking.  See my above statement for what coop can do, and notice 
> > that on the other hand, preemptive cannot ever fail to preempt or it 
> > completely fails.

>   That last bit about preemptive cannot ever fail seems redundant to me. 

Not to mention needlessly repetitive, yes.  I was trying to avoid the 
traps of subtlety.  :)

> But to impliment preemptive multitasking within a cooperative multitasking
> system there has to be some facility to interrupt a currently running
> execution unit, else you can't preempt it!  And if this isn't the case, then
> you very well CAN'T do preemptive multitasking.  Well, you can, but it'll be
> a horrible kludge.

Notice, though, that the only thing that needs to be added is the ability 
to stop execution of your own children/subobjects (hey, the right to 
choose!  Sorry.).  This may be hard or easy, depending on the system, and 
it certainly should be provided in at least a primitive form by the 
system, but the system does not need to excercise it.

>   But I contend that preemptive multitask is more flexible than cooperative
> because you CAN do cooperative multitasking in a preemptive multitasking
> system.  And to prove it, I'll do it!

Nice, but one huge problem.  You've just written a system that has ALL of 
the disadvanteges of coop AND all the disadvantages of preemptive.

To be more specific, the code which we've proven can and should use coop
(in this case, your 'task' function) is being preempted by the OS unless you 
turn preemption completely off, thus bringing everything else to a halt.  
So not only are you being required to use a non-optimal task switching 
algorithm, you're also using another one (the intended one this time) on 
top of it!

Cooperate is more flexible than preemptive simply because it's more 
primitive, more basic.  Preemptive is a simple addition to cooperative, 
and could easily be done in a small part of the system without requiring 
any change to the rest.

-Billy