release 0.0.0.20 and thoughts

[spc@gate.net]

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.

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

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

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

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

  If I wanted to, I could write the code to do I/O within this framework, as
there is (within AmigaDOS) the ability to aquire access to the hardware in a
controlled mannor.  So, yes, if I wanted to, I could do a completely
cooperative system.

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

  And what's non-optimal about it?  The method used is, more or less, the
implimentation discussed on this list.  Yes, I had pretty much re-impliment
task switching (and note:  the preemptive task switcher only saves two more
bytes of state information on the Amiga, and that is done pretty much by the
hardware anyway), but only because there is no information about the
following functions (which do exist on AmigaDOS 1.3 (what I run)):

		Supervisor()
		ExitIntr()
		Schedule()
		Reschedule()
		Switch()
		Dispatch()
		Exception()

  I'm sure that if they were documented, I could have used them.

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