From: johnsd2@vccnw07.its.rpi.edu (Daniel Norman Johnson)
Newsgroups: comp.sys.mac.advocacy
Subject: Re: the NeXT option (Was Re: 7.1 vs. OS/2 and Windows NT)
Date: 6 Nov 92 21:26:03 GMT
Article-I.D.: rpi.jak1=sl
Reply-To: johnsd2@rpi.edu
Organization: Rensselaer Polytechnic Institute, Troy, NY.

In article <1992Nov6.121308.4320@cubetech.com>, andrew@cubetech.com (Andrew Loewenstern) writes:
|> In article <2wh14#q@rpi.edu> johnsd2@rpi.edu writes:
|> >In article <TTN.92Nov5095242@mustarastas.cs.tut.fi>, ttn@cs.tut.fi (Tero Nieminen) writes:
|> >|> In article <c!h1_p+@rpi.edu> johnsd2@jec313.its.rpi.edu (Daniel Norman Johnson) writes:
|> >|> 
|> >|>    In article <1992Nov4.044023.819@cubetech.com>, andrew@cubetech.com writes:
|> >|> 
|> >|>    |> the function call to cause a
|> >|>    |> context switch and tell the thread scheduler to make a different
|> >|>    |> thread runnable is called cthread_yield().
|> >|> 
|> >|>    Ah, but this will be usefull to me since by Eds (admittedly strange)
|> >|>    definitions, this makes Unix a co-operatively multitasking system,
|> >|>    since tasks (particularly X-windows tasks, I bet) can/probably do
|> >|>    co-operate by calling sleep!
|> >|> 
|> >|> Notice that the routine name refers to threads (light weight processes).
|> >|> Threads are cooperatively multitasked. Since each program has it's own
|> >|> set of threads, it is assumed that the programmer knows what he is doing
|> >|> and cooperates between the threads as he sees fit. It is completely
|> >|> another thing to schedule processes, which still is preemptive.
|> >
|> >Ah; so it doens't pre-emptively switch from thread to thread
|> >just process to process.
|> >
|> >More ammo! :) Thanx!
|> 
|> NO!  Excuse me from using the term thread.  I am used to using threads
|> on Mach.  On Mach, everything is a thread, and threads are grouped
|> into processes (where they share the same address space among other
|> things), and they are the base unit of the task scheduler.  They are
|> all premptively scheduled.  The situation which you describe is SunOS
|> (?)  where each task is scheduled, and the threads (a.k.a. lightweight
|> processes on SunOS) co-operatively schedule themselves within the
|> task's time-slice. This is not the same situation to which I am
|> referring.  Therefore I will stop using the term threads.

So on SOME systems threads a co-operatively multitasked within a processes,
but in others they are just processes (but they share memory spaces
with other processes)

|> Here is a good example of using something like cthread_yield in a
|> preemptive multitasking system:
|> 
|> while(1)
|> {
|>   if(check_something())
|>     {
|>       do something;
|>     }
|>   cthread_yield();
|> }
|> 
|> 
|> Now, if you remove "chthread_yield()," you will run in a very tight
|> loop (if check_something() returns false often) and chew up a lot of
|> CPU time, but since the system is preemptive, other tasks will still
|> run (but a tight loop like this still chews up a lot of CPU).
|> cthread_yield() tells the system "go ahead and let other stuff run
|> now" an every turn of the loop instead of looping until it used it's
|> time slice (which, on a fast processor, could be several hundred or
|> thousands of loops).

It looks like in this case cthread_yield will make this loop
switch out much, much more often than it otherwise would have. Why
is this necessary? The thread should be pre-empted during the loop,
regardless of what its doing, right?

|> Sleep() on the other hand, makes your process idle for a set amount of
|> time.  Yielding just makes you idle until it's your turn to use the
|> CPU again.  You don't _have_ to call it, but in situations where you
|> don't have to burn the CPU, and don't want to put in a fixed delay,
|> this is the way to go.

Right. I knew this.

|> 
|> this really isn't that difficult.
|> 

Only if its explained accurately. This

"Threads are co-operatively multitasked"

is what Tero said, and I believed it. Its still up there,
actually, so you can see the context. I don't think I need
to appeal to stupidity to explain why I didn't get it.
-- 
			- 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.