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

[vandry@CAM.ORG (Phillip Vandry)]

slp@vax1.mankato.msus.edu writes:

>pointless for the task switcher to save registers that the programmer and/or
>compiler are EXPECTING to be changed by the call!

Even if multiprogramming had to save less registers than multitasking (using
correct terminology!) it would only be by a matter of bytes. 20 extra
processor cycles MAX MAX MAX. Big deal, especially whn you consider the
disadvantages ofmultiprogramming.

>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.

Except would you rather have switches occur automatically at regular
intervals or have to force the switch yourself. Instead of "Is it time
yet? No. Is it time yet? No. Is it time yet? No. Is it time yet? No. Is it
time yet? Yes." preemptive uses a fomr more like ".........It'ss TIME now!"
More efficient if you ask me...

>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?

If you're accessing a global while you call EventAvail you would need some
kind of synchrnoization even in cooperatve! No difference. Only usually
multiprogramming refrains from ding that in the first place, placing
restrictions on the programs.

>>> 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

OK. Sorry. You said "Should" very emphatically.

>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.

Yes, but again this is a special casing thing. The program had to be specially
made to do that. You should b able to run multiple copies of a single user
BBS program ad obtain a perfectly great multi user BBS system.

The program that was specifically written to do that has to manage the
variou users' actions and the processes they are running because the
cooperative system won't do it fr you!

And th problem still remains: What if a non ultitasking compatible
program is run in  coop system? Everything could halt for seconds at a time.

Also coop sytems don't generally implement such neat things as pipes and
ttys as UNIX does
 ______________________________________________________________________
|~~~~~~~~~~~~~~~~|~~~~~~~~~~~~~~~~|~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
| Phillip Vandry | Vandry@Cam.Org | Suicide (n.): What to do if Macs   |
|________________|________________|_______________take over the world__|
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~