coop/preempt [was: Re: release 0.0.0.20 and thoughts]

[Billy Tanksley]

On Tue, 22 Aug 1995, Tommy Hallgren wrote:
> Billy wrote:
> > On Mon, 21 Aug 1995, Rainer Blome wrote:

> > > how much speedup do we get from coop?  will it be so much that it is worth
> > > investing the time needed to implement it?

> > A _very_ good question, worthy of testing, IMO.

> They way I see it it will slow down things. For example, the Amiga uses 
> messages to send commands to devices, let's say I make a program that
> send a command to the harddrive device that says 'read 100 tracks and put it 
> here'. On the Amiga, the transfer from the drive to memory is probably DMA-
> driven so the device suspends itself until the transfer is done. And when the 
> transfer is done the device code will be awaken immediately since device 
   tasks
> run at a higher priority, and the first things the device does is to reply 
   the 
> message.

What in the world does this have to do with cooperative or preemptive 
multitasking?

> As I see it this will probably max out the harddrive even with a slow 
  processor.

> Can anyone explain how coop mt can be used to elegantly do equally same 
> performance wise?

Well, it's hard to say-- I don't see any use of multitasking in it at ALL.

Your nex paragraph should have (IMHO) been three seperate paragraphs, 
since the thoughts had no real connection.  I've responeded in that way.

> I would really hate a cooperative mt system.

That's a drawback.  Coop has a bad image, earned from many bad 
implementations.  In addition, coop is strictly less than preemptive 
(which is an advantage to the system, but a disadvantage to any marketing 
department).  Nonetheless, the fact that you, or anyone else would hate the 
system should not dissuade us from considering it.

> Different tasks have different importance 

True.  However, that has NOTHING to do with preempting tasks, but only 
with delivering control.  In a good system, control will be given to the 
task that deserves it the most.

> and only with pre-emptive mt it's possible to make a responsive and 
> flexible os.

That's begging the question.

> > Implementing coop will be incredibly easy.  Implementing proofs will be 
> > dramatically harder, BUT will allow many good things.

> Once pre-emptive mt have been implemented the entire OS will be better, IMO.

Again, begging the question.  The OS needs preemption, but it does not 
need preemptive MT.  We need to be able to stop a runaway program, but we 
don't need to stop every program as though it were runaway.

> > 1) preemptive is far harder to implement than coop.

> Have you tried?

Of course!  Coop is far easier; you don't require a preemption capability.

> > 3) coop is easy to run under preemptive; you can just compile out the 
> > yields (or even just keep them in).

> If you have pre-emptive, why should you want to implement coop?

You wouldn't.  It would be redundant, like putting a yield sign on a 
brick wall.  That paragraph was referring to the compatibility of code 
written for a cooperative system; it will work whether or not there is 
cooperation.  In contrast, preemptive code will fail on a cooperative OS, 
since it never relinquishes control.

Naturally, TUNES should provide for ill-behaved programs, but we don't 
have to design our whole system around htem.

-Billy