From: johnsd2@vccnw07.its.rpi.edu (Daniel Norman Johnson)
Subject: Re: the NeXT option (Was Re: 7.1 vs. OS/2 and Windows NT)
Reply-To: johnsd2@rpi.edu
Organization: Rensselaer Polytechnic Institute, Troy, NY.
Date: Fri, 6 Nov 1992 00:56:56 GMT

In article <1992Nov5.075315.2269@cubetech.com>, andrew@cubetech.com writes:
|> In article <_+f1tvp@rpi.edu> johnsd2@rpi.edu writes:
|> >In article <ewright.720722961@convex.convex.com>, ewright@convex.com (Edward V. Wright) writes:
|> >|> In <acb18_+@rpi.edu> johnsd2@vccnw03.its.rpi.edu (Daniel Norman Johnson) writes:
|> >|> 
[deletia- a typo]
|> >
|> >That's nice. Its dubious that this is "chewing up all the CPU
|> >time", but that's not terribly important.
|> >
|> >However, co-operative mt is decidedly less efficient in these
|> >cases- efficient enough to do downloads, but it could be better.
|> 
|> That is totally false.  cooperative multitasking is _always_ more
|> efficient than premtive MT, *especially* when you have many threads
|> and the load is high.  Why?  There is far less overhead in a
|> cooperative MT system.  One thread simply calls the yield function,
|> the kernel sticks that thread at the end of the run-queue, and begins
|> executing the thread at the head of the run-queue.

With a co-operative system you must call this routien very often,
with all the overhead that entails. With a pre-emptive you do NOT;
the switching can be must coarser because if something of interest
occurs (mousedown say) the current task can be pre-empted- you dont
have to wait for it. You still have to have regular switches everyon
couple of seconds at least. This is rather less often than the
co-operative system requires. Id say that makes it more
efficient.

|> NetWare is a multithreaded operating system.  But it's cooperative mt,
|> and has no memory protection (much like a macintosh).  Threads must
|> call ThreadSwitch() to yield the processor.  Novell reccommends that
|> you call it *often.*

Its a good idea too.

|> NetWare is mainly a file-server operating system, and it's very highly
|> optimized for speed.  In fact, cooperative mt and no memory protection
|> or virtual memory space was specifically chosen because it was more
|> efficient.  Novell licenses NetWare based on the number of concurrent
|> users.  It starts at 100 users and goes up to 1000 (one thousand).
|> Would you put even 50 users on one AppleShare file-server?  Forget
|> file-serving.  If you had enough memory, would you run 50 pieces of
|> software at once on a Mac assuming that 5 at any one moment would be
|> using the processor to do something?

Im not familiar with all the design decisions in NetWare. I
know memory protection and virtual memory slow things down.

As to the co-operative mt, well I cant say for sure but it could
well be that in a dedicated server they need to be very carefull
about when they yield time so as not to disrupt anything. Alternately,
maybe they decided that very few people would try to run apps under
NetWare  directly (instead of just running DOS apps), they may
well have figured it just would not matter in that case.

|>  Heck, I can cause a download to
|> fail on a Macintosh by just using one application!

I've never managed it, but I hear this is possible. It owuld not
be under pre-emptive multitasking.

|> The difference is on a file server, you run much less software (as in
|> different pieces from different places rather than the number at once)
|> than you would on a PC like a Macintosh.  For instance, you might run
|> a few pieces of software from Novell (like NFS or AppleShare), maybe
|> some UPS software, and possibly a database server from Oracle or
|> Sybase.  But not a whole lot more.

True. Just as I was thinking, a paragraph ago.

|> On a Macintosh you run all sorts of software coming from all sorts of
|> people and companies, and Macintosh software isn't required to go
|> through testing by Apple before the company can claim it's Macintosh
|> compatible (like you have to do with NetWare Loadable Modules).
|> 
|> The problem isn't that cooperative MT isn't efficient, it's that the
|> software isn't yielding the processor often enough.  I think part of
|> the problem is that the thread yield functions on Macintosh are
|> directly tied to the event dispatcher.  So you have software that
|> isn't yielding the processor until it's done doing whatever it's doing
|> and is ready to process the next event.  Mainly because in many
|> situations, it's very difficult to process more events and continue
|> doing whatever it was that you were doing.  It's all this between
|> event processing that's the problem since it blocks all the other
|> tasks.  On a preemtive MT system, the application can spend as much
|> time as it wants processing in between events without blocking other
|> threads.

Believe it or not, I mostly agree. I dont think the slight
inefficientcy of co-operative mt really matters.  Its just one
more little point I dreged up in my arguments.

|> The bottom line is that cooperative mt is definitely more efficient
|> that preemptive mt, but preemptive mt is far more _appropriate_ in a
|> user environment where you can't count on every application to be a
|> "good-guy" and yield the processor often.  This is why unix, and VMS,
|> and VM, and MVS, and so on are all preemptive - they are designed to
|> be used directly by users.

I still feel that pre-emptive mt is more efficient. So there. :)


-- 
			- Dan Johnson
And God said "Jeeze, this is dull"... and it *WAS* dull. Genesis 0:0

These opinions have had all identifiying marks removed, and are untraceable.
You'll never know whose they are.