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

[slp@vax1.mankato.msus.edu]

(If you mail replies to this message, please mail them to "gtr@tfsquad.mn.org"
rather than the address listed as "From" here.)

rhyde@ucrengr.ucr.edu (randy hyde) and bazyar@teal.csn.org (Jawaid Bazyar) are
confused about the fact that a cooperative multitasking system doesn't need to
save as many registers and such during a process switch as a preemptive system.
The reason for this is because a cooperative multitasker only switches during
function calls, when registers are expected to be nuked anyways.  It would be
pointless for the task switcher to save registers that the programmer and/or
compiler are EXPECTING to be changed by the call!

vandry@CAM.ORG (Phillip Vandry) makes some comments about a cooperative
multitasker distinguishing between foreground and background processes, and of
the need for the programmer to write special code to support it.  These
attitudes are understandable from someone who only has the Macintosh OS as an
example and is not too familiar with the concept in general, but it is most
definately a misconception.  If the OS can switch processes on any call to the
system (not just WaitNextEvent & EventAvail for example) then writing a program
that cooperates and multitasks smoothly is no big problem, and requires no
special effort at all whatsoever beyond having to occasionally make an OS call.

I find it funny that the same people who complain about the pain of needing to
call EventAvail once in a while seem to think calling a semaphore whenever you
need to access a global is no big deal.  Huh?

Regarding the ZMODEM example: Let's be a little more realistic, shall we?  I
have yet to see a serious implementation of a transfer protocol that doesn't
use buffering.  Because interrupts are off during a process switch on most
preemptive systems, whereas they can be on in a cooperative system, the fact of
the matter is, preemptive multitaskers are more prone to the "lost characters
during a high speed transfer" problem than coopertive systems are.  I'm not
saying they are a problem.  Most preemptive systems can switch fast enough that
you don't loose characters.  I'm simply pointing out that it's far more likely
to cause a problem on a preemptive system than a cooperative one.  The whole
argument is bogus in the first place, but if you're going to use it, keep it
straight which system is more likely to have the problems.

(By the way, I am the author of some BBS software, as well as someone who has
written both cooperative and preemptive threading programs before.  I'm all too
well aquaited with the problems of implementing transfer protocols, as well as
multitasking executives.)

>> This is what you're saying:
>>         Therefore single user must use coop and multi must use preempt

Excuse me?  I never said that, not did I mean to imply it.  My original post
dealt with the whole issue in general, and like all generalities, it can be
proven wrong for specific examples.  Like the famous quote says, "All
generalizations are bad."  :)  MUST is definately not a word I would use in the
above quoted sentence.

And by the way, cooperative multitasking is definately not impossible on a
multiuser system.  The author of XBBS wrote an excelent article in The C Users
Journal a few months ago which describes the multitasking state machine he used
for his multiuser bulletin board system.  It's not an approach I would use
myself, but it provided some interesting insights.

On that note, I'd like to point out that The C Users Journal had a number of
articles on multitasking in the last half a year or so.  Both cooperative and
preemptive approaches where featured, as well as articles on how to implement
either approach under OS's that provide no help for threads in your programs.
If you're interested in this topic, you should try and dig these up.  Many of
you have a number of misconceptions about coopertive systems -- this might even
be educational!  :)

-GTR