cooperative versus preempt

Billy Tanksley tanksley@mailhost2.csusm.edu
Wed, 23 Aug 1995 15:53:47 -0700 (PDT)



On Wed, 23 Aug 1995, Frank DiCostanzo wrote:

> it would seem a few major issues about this are being ignored:

> 1.  wouldn't it be easier to exploit multiple processor architectures and 
> distributed computing under preemptive threading? is tunes a single 
> processor OS, end of story?

No, because MP is an issue related to contol _delivery_, not control 
return.  preemption vs. cooperation deals only with control return (to 
the OS).

> 2. as more and more OS's use threading, the hardware people will come 
> around and implement threading in the processor.  state changes and 
> object protection won't take any noticable time at all.  it happened with 
> floating point and memory management, its only a matter of time for 
> threading. (and hopefully garbage collection)

Two things.  First of all, threading is the same as multitasking-- no 
real difference, except the overhead.

Second, nothing is without a cost.  If they implement threading in 
hardware it will cost, just as it costs to rum memory management in 
hardware.

> 3.  who really cares if a percentage of time is spent dealing with 
> threading?  as someone posted earlier, one can just wait a year and 
> processors will double in speed.

Wow, will mine do that too?  Last I checked, time increases entropy, not 
decreases it.  :)

Seriously, though, TUNES cannot be designed to run ONLY on the 
cutting-edge models.  I woud have NO objection to using ONLY preemption 
on those cutting edge models, though-- if it had no other cost, it 
certainly is nice to program for.

> 4. real time computing requires preemptive scheduling.

Nope.

>  Frank DiCostanzo

-Billy