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

[Billy Tanksley]

On Tue, 22 Aug 1995 rdm@tad.micro.umn.edu wrote:

> Billy Tanksley:
>    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.

> The reason coop has a bad rep is that the performance of the system --
> as a whole -- depends very strongly upon the individual apps.

That's true.  That's why I'm pushing for provability.  The only reason 
I've talked more about coop than provability is that everyone sees 'coop' 
and jumps on it.  The problem (as I see it) is that true preemption-- 
that is, the interruption of a task whenever another task needs it-- is 
sometimes bad for the running task, and always a load on the system (from 
state saving).

To tell the truth, the reason I started going on about coop was that it 
seemd to be moderately accepted here-- Fare' was supporting it with 
fairly low resistance.  There were only a few challengers, one of which 
was me.  What changed my mind was the idea of proof-- if the program 
proves to the system where it can be interrupted with a minimal amount of 
state-saving, the system can just throw the interruptions in there with 
all the state-saving pre-configured.

> The code could perform very well under cooperative multi-tasking, but
> then it might be re-configured (customized) by some end-user in a way
> that the original designer hadn't considered.  Here, there might be a
> 5-30 second pause while some normally "almost instant" operation is
> being performed.  Now, the system is crawling and there's no real
> recourse without re-building the entire application.

True.  However, that's under proofless MT.  With even a low degree of 
forknowledge, the system will be able to schedule tasks around such 
occurances.

> It's just too easy to write some application in a
> non-cooperative-multitasking-friendly manner, because "it'll never be
> a problem."  Remember, most proofs are going to be about specific test
> cases, rather than any sort of general case.

Just remind the user to be sure to only run specific software on their 
computer.  (Sheesh, I wasn't aware that you could run anything else).

> Or, another way of looking at this is: the effort you save by not
> providing pre-emptive multi-tasking in the OS is going to have to be
> made for each application that needs pre-emptive multi-tasking in a
> cooperative multi-tasking environment -- as well as all applications
> that will be run with it.

I said this over and over again, but nobody seems to hear!  I DO want 
preemption to be possible and provided.  I DON'T want it to be required 
and used every 1/60th of a second, whether it's needed or not!

Preemption CAN be used to ease deadlocks, but it doesn't need to be used 
for everything else also.

> Raul

-Billy