Re: "Real" Multitasking (Re: GNO questions...)

[toddpw@cco.caltech.edu (Todd P. Whitesel)]

vandry@CAM.ORG (Phillip Vandry) writes:

>(The following is not a disagreemtns in any way, but a reinforcement of the
>point in an effort to further defend preemptive multitasking, UNIX, and GNO/ME)

Whoa. This whole thread isn't, and NEVER REALLY WAS, an _attack_ on preemptive
tasking, UNIX, or GNO. All GTR did was stand up and say "cooperative tasking
is useful sometimes", and -WHAMMO- there was a massive dogpile. If anyone had
actually READ what he wrote _and_ thought about it before cutting loose with
the flamethrowers, things would have been a lot more civil and most of the
argument wouldn't even have happened. This sort of childish behavior is what
drives a lot of people off of c.s.a2.

>But if they do not give up their time, it will be taken away soon enough!

Very true. I referred to that.

>that reason, I don't think you can get away with defining that as cooperative
>multitasking. All of the concepts, systems, etc. of preemptive multitasking
>still apply. Although blocking a process is similar to cooperative
>multitasking's technique, the concepts of coop are simply not there.

"concepts of coop"? I think you lost me.

If you really think about it, EVERY system that can handle interrupts has
elements of both in it. Forget what "kind" of system you're on for a minute.
There are three basic methods of scheduling execution:

- interrupt handlers are pre-emptively tasked processes who are not
	allowed full I/O and memory facilities for performance reasons.
	They are also _required_ to give control back to the system
	or else things stop working. unix device drivers fall into this
	category, as do device drivers for most other O/S's.
- any time you call the system so that you might be switched out, you
	are cooperative scheduling your own process, because you are
	voluntarily giving control to the system with the machine in
	a known state (i.e. function call or trap). On machines with
	lots of hardware context to save (i860!!), this can make a
	noticeable performance difference.
- any time an interrupt comes in that might force your process to be
	switched out, the O/S is pre-emptively scheduling your process,
	because you are involuntarily giving control to the system with
	the machine in an _unknown_ state. This is the element that is
	required for most people to refer a system as pre-emptively
	multitasking, because it can pre-emptively task arbitrary programs.

What was the point of all that? To communicate the idea that a lot of people
seem to be missing: coop vs. pre-emptive aren't two mutually exclusive states.
They're building blocks that very happily coexist, and you need them both to
build a well-balanced system.

I might add that another often-overlooked fact of unix is that the kernel
usually cooperatively tasks its internal operation, because trying to make
every device driver re-entrant and keep all of the semaphore communication
straight would be a total nightmare, so nobody in their right mind does it.
Educational systems like Minix really do premptively task chunks of their
kernels, but that means they have to pass loads of messages around which
really eats performance (and the authors freely admit that fact). Real world
example: Sun NFS only handles multiple outstanding file server requests by
running multiple instances of the client & server daemons, so that each one
provides a seperate context and neither the kernel nor the device driver has
to. If you don't run those daemons, then network file service suddenly becomes
as synchronous as a local disk -- more synchronous, in fact, because only one
NFS I/O request may be outstanding at a time in the entire _system_. Sun ships
the O/S running between 4 and 8 of those daemons, and no one seriously thinks
about not running them.

The same applies within a single process: Xlib (the "toolbox" library for
X windows) is totally nonreentrant and does not even have a busy flag, so if
your process wants to make an X call from a signal handler you'd better be
damn careful or Xlib will blow big meaty chunks all over your process. If
you want multi-threaded use of Xlib within your own process, you have to
cooperatively task it yourself.

What many people don't realize (and what GTR, and someone else whose name I
forget, was trying to say) is that when you have control of the system and
know that things will work, cooperative is better because it has less overhead
and far fewer communication issues. Pre-emptive is required for running 'other
peoples programs' when you can't trust them to coop nicely, or when you need
an element of real-time in the system -- and that can usually be done with
interrupt handlers and not a full pre-emptive scheduler. The whole point of
unix is to use each technique where it works best, and if anything most unix
systems try to put all the pre-emptiveness in the kernel interface so that
nobody else is forced to worry about it.

Todd Whitesel
toddpw @ cco.caltech.edu