From: chris@atl.scscom.com (Chris Boaro)
Newsgroups: comp.os.os2.misc
Subject: Re: preemptive multi-tasking
Date: 16 Apr 92 15:14:55 GMT
Organization: SCS/Compute, Inc.

crum@edwards-vax.af.mil writes:


>  Now I'm confused about this preemptive multi-tasking thing.  Are you saying
>that if I have 4 DOS applications open in MS Windows and 3 are idle in the
>background, that only the forground application will get CPU cycles, and the 3
>in the background will get none as long as they are idle?

>  If one of the background DOS applications is a communications program which
>is not receiving anything, then a download begins, will it take CPU cycles 
>from the forground application as needed to prevent loss of data?

>Please explain.

Multitasking explained:

There are two types of multitasking, cooperative, and preemptive. In short,
in a cooperative system, all applications are coded to specificially 
give up the CPU while they are executing. For example, a Windoze application
executing a tight loop waiting for input, might pass the cpu off to some
other process after every loop iteration. If it didn't do that, other
cooperative tasks wouldn't get any cpu time at all.

Now, in a preemptive multitasking system, the operating system alots a certain
amount of cpu time to a process (or thread, under OS/2), and yanks the cpu
away from that task when it's time slice has been used up.

Windoze has a preemptive multitasker in that it switches between DOS tasks
and Windoze cooperative tasks. All windoze applications share one slot in
the preemptive scheduler. No DOS multitasker can be cooperative, since DOS
applications aren't written to give up the cpu. 

Under OS/2, all applications except those running in the windoze emulator
are preemptivly multitasked. While the entire windoze emulator is preemptivly
switched, the applications running inside of it (windoze apps) are cooperativly
multitasked.

If you're lost, you're not the only one. 

Now, for simplicity, many people say that preemptive multitasking is "good"
and cooperative multitasking is "bad". The problem with this is that 
just because a scheduler is preemptive, doesn't mean that it's efficient.
Let's say that you're running a scheduler that multitasks DOS applications.
Let's go on to say that this scheduler is running 10 DOS applications. As
we said above, DOS applications can't be multitasked cooperativly, so 
naturually our scheduler is running preemptivly... stopping each application
when it reaches the end of it's time slice and passing the cpu off to the
next application in the run queue. Since it's difficult for our scheduler
to know when each ap actually NEEDS cpu cycles, we have to allocate a fixed
amount of time to each one. If you take a moment to consider this, what's
happening is that we're wasting a lot of cpu time. Applications that might
be spending most of their time waiting for disk or keyboard i/o are now
getting just as many cycles as the spread sheet recalc that needs lots
of cpu cycles. In addition, applications waiting for keyboard I/O in
the forground will have to wait for the time slices of every application
in the run queue before it to complete before it can recognize and
process the keystroke.

The previous is an example of why preemptive does not always equal
efficiant. But the situation isn't as grim as it may sound. There are
things that can be done to make the system more efficiant. Both OS/2 and
Windoze use tricks to figure out when DOS tasks are sitting idle waiting
for I/O, and when they really need the cpu. However, even under the
absolute best circumstances, these schedulers can only do so much. Built
in to nearly every DOS application, there are simply too many places
where hardware is directly accessed, and therefor impossible for the
scheduler to detect. The problems involved with multitasking DOS applications,
then, are not solely due to our scheduler, but to the actual applications
themselves!

The solution to this bottle neck is to start from scratch with a brand
new operating system. One that handles ALL I/O by it's very definition.
One that won't let applications haphazardly muck with the hardware. If
we can say for sure that the operating system is going to handle ALL
I/O, we can say for certain that the operating system will know when
an application needs cpu cycles, and when it's just waiting for I/O.
Hence, this is the logic used to justify the creation of OS/2. OS/2
applications use the operating system exclusivly for I/O. So, an application
that is just sitting around waiting for a user to type a keystroke would
get basically zero cpu time, while a compile in the background would get
plenty of cycles. However, the very instant that the user presses a key,
the operating system can preempt the compile, and pass control back to
the forground application. This system makes it possible for multitasked
OS/2 processes to run FAR FAR more efficiantly then even the most optimum
scheduler can handle DOS tasks.

I hope this has helped some of you understand the basics of multitasking.
And to those of you who would burden this description with more technical
details, yes, I realize that the above is a simplified version of reality.
Please don't explain that to me.

Chris