Stefan van der Walt wrote in a message to Mike Bilow:

 SvdW> You got yourself a credit in our maggy!

Thanks...

 MB> I suppose you can release the timeslice whenever your program is idle.
 MB> This is not to be misinterpreted as a license to write polling loops
 MB> in programs to be run under OS/2, since these will have other bad
 MB> effects involving such things as memory paging even if the CPU is
 MB> released. 

 SvdW> Let me get this straight.  You do NOT want as much timeslices 
 SvdW> as you can? When then?  I have a sound system working in the 
 SvdW> background... 

In general, OS/2 has a scheduler which can be relied upon to decide how
busy a program is, and best efficiency is reached when it is allowed to do
its work.  There are several specific exceptions, and one of those is DOS
programs running under OS/2 because DOS programs frequently execute in idle
loops which look like real processing to OS/2.  In such cases, if you
cannot easily rewrite the DOS program to get rid of the idle loop, making
explicit yield calls is a good idea.

In native OS/2 programming, what you usually want to do is wait for events
of some kind, either for a keystroke, a mouse movement, a disk read, a
serial port character, and so on.  When waiting for such events, the
program consumes no processing time.  In some cases, a program is most
naturally implemented as multiple threads, each waiting for a different
event.  Even DOS programs can make calls to wait for the next keystroke,
and OS/2 handles this correctly.

Now, if one programmer writes code to run at full bore and another
programmer writes code to make explicit yield calls just to be nice, and
their programs are run at the same time, then nice guys will finish last. 
Even if all programs make explicit yields, making too frequent yield calls
may increase the proportion of time spent switching tasks rather than doing
useful work.

There is a trade-off between efficiency and responsiveness, since
efficiency is greatest when no task switching is done and all tasks are
serialized.  However, responsiveness is usually constrained by external
real-time issues, such as user perception or incoming serial data.
 
-- Mike


---