PH> AFAIK there is/was a little bug (?). DosSleep (0L) 
 PH> won't release a complete timeslice, but DosSleep (1L) 
 PH> will. I'm not very sure about this, but after a few 
 PH> tests, I got very different results from those two 

Here's the beef:  DosSleep(0) releases the remainder of the current
timeslice to any thread of equal or higher priority,  if such a thread is
currently scheduled to be run.  If no such thread exists, DosSleep will
return immediately.

DosSleep(1) will cause the current thread to to marked as idle.  Any thread
that is ready to run will be,  even if it is a lower priority. The thread
that called DosSleep(1) will have to wait until it is its turn to be
scheduled again,  which could be quite some time if there are lots of other
threads waiting to run.  Additionally,  the values passed to DosSleep() are
rounded up to the next scheduler period (usually 32ms).  So DosSleep(1) is
the same as DosSleep(31).

Since the program in the foreground usually gets a "foreground
boost" from the scheduler,  it will have a higher priorty to similar
programs that are not in the foreground.  You can see,  therefore,  that
the likelihood of there actually being a thread (greater or equal in prty)
ready to run when DosSLeep(0) is called is not that large.

Moral of the story:  Call DosSleep(1) in your polling loops,  or else
"Pulse" will be unhappy.

 PH> When measuring 64 Threads usind DosSleep(1L), the CPU 
 PH> load raises to 17%. When doing the same with 
 PH> DosSleep(0L) to "pre-empt" the current thread 
 PH> voluntarily, the CPU load raises to 100%.

The "Pulse" program is not very useful,  but we are all stuck
programming for it, now that all the lusers are running it.

Pulse measures the amout of idle-time slices that are available,  and then
plots this upside down.  ie: When none of the idle-time slices are
available,  it plots 100%;  when all of the idle slices are available,it
plots 0%.  

What this does not show,  and which is much more interesting,  is if the
CPU is available for demand.  I can write an idle-time loop that will cause
Pulse to show 100%,  but the CPU is COMPLETELY available for any
"normal" priority thread that comes along.  In fact,  Pulse
relies on this -- it has such a loop inside of itself.  So when nothing
else needs your CPU,  Pulse is using all of it (and showing 0%). (Try
starting two copies of Pulse, one will show 50%!)


--- Maximus/2 2.01