release 0.0.0.20 and thoughts

[Billy Tanksley]

On Sat, 19 Aug 1995 spc@gate.net wrote:

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

> > >> 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.

> > 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.

>   They are?  In some cases, where most data is statically allocated (during
> load time), yes, it may (may) be possible to anticipate the working set
> (read: swap demands) for both code and data, but in any code that
> dynamically allocates memory (read:  creates objects) the problem starts
> getting harder.

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 :).

> > 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! ;).

>   And I've yet to see a program crash because a critical data structure was
> swapped out.  Usually, if they're critical, they're locked into memory and
> can't (or won't) be swapped.

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

> > > 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.

>   And as someone else pointed out, you also need to provide atomic
> operations.  In order to provide the ability to do preemptive multitasking
> cleanly, you pretty much have to provide preemptive multitasking in the
> first place.

Yes.  The ability to preempt should be written by the system designers.  
I see no reason to write preemption out.

However, there's a big difference between permitted preemption and 
required preemption.

> > >   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.

>   Wait!  I thought you were arguing that cooperative is GOOD?  Now you're
> saying that my code has the disadvantages of cooperative multitasking?  I've
> been arguing that point all along.

Then we have found yet another way we are in agreement.  I have yet to 
find a system without faults (although you'll hear me allege this for 
Geos and/or Forth, it's not true ;).

Coop DOES have disadvantages.  That's why I support including 
preemption.  Preemption also has disadvantages, which is why I dislike 
requiring it.

> > 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.  

>   Note, however, that within the program, the task switching is done
> cooperatively, as per the methology discussed.  Yes, it is preempted to
> allow other tasks to run, but remember, AmigaDOS was designed to be a
> preemptive system.  I implimented a cooperative multitasking program within
> that system.

I never questioned whether that could be done!  I still don't.  It's easy 
(not trivial, since it took more than 10 lines of code), but it can never 
solve any problems.

Actually, I think I do see a way to do what I'm thinking of: if the 
cooperative engine would shut off the preemption while it was 
actually running a task (assumption: the calls to pause are properly 
placed).  This way, the tasks can benifit from not being prempted (which is 
presumably why TUNES put the tasks into cooperative mode).

In other words, give the cooperative MT the control over the system.

I don't see why to not give the control to the coop in the first place.

> > 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!

>   Again, what exactly are you arguing for?  Cooperative or preemptive?

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

Some tasks benifit the absence of preemption).  Others benifit from the
absence of the pauses required for cooperative.  Neither should carry any
of the baggage of the other. 

> > 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.

>   Preemptive is not a "simple addition".  Unless you like starving
> philosophers.

>   -spc (Or races ... )

Starving philosophers?  Or races?  What?

Preemptive is not simple to implement portably, I'll give you that.  
Preemption needs to be an ability provided as part of the specification.  
However, it does not need to be used to implement all multitasking.

-Billy