Hey ppl!

 I've been away for a rather long time (no, not in jail!!!) as I had a
 long and hard exam season, then went on a vacation trip to Budapest,
 and when I returned, I found out that my second hard drive (apparently
 feeling neglected by me) has commited suicide... poor thing :~(

  Anyway, I recovered most of the data, and here I am once again, ready
  as always to bore you to death with my long messages full of
  whining... :)

  So, let's get back on topic... I wasn't sure whether to put this
  question here, but as it has to do with the internal design of OS/2
  (hope Dennis Tonn is reading this and responds), I think this echo is
  most adequate.

     It's about PRIORITIES

  I can't claim that I know much about the internal workings of OS/2, so
  I'll present some of my explorations and experiments that lead me to
  conclude certain things which may or may not be correct (feel free to
  answer this question)

  From the information I managed to gather (and I used mostly my Borland
  2.0 compiler and Process Commander II), there are four classes of
  priority with 32 levels each, totaling 128 priority levels. Classes
  are Idle, Regular, Time Critical and Foreground Server. The first
  thing that strikes me as strange is that although the clases are
  enumerated in this order, Time Critical has actually higher priority
  than Foreground Server. I wonder why it isn't the last...

  We all know that OS/2 is a true 32-bit preemptive multitasking and
  multithreading operating system, but let's just see how preemptive it
  actually is. It certainly has the CAPABILITY to be preemptive, but is
  it used to it's fullest extent? I'll demonstrate what I mean by simple
  experiments.

  Let's open up two OS/2 command line windows. In CONFIG.SYS I have
  PRIORITY=DYNAMIC and MAXWAIT=1.

  They both run at priority 0x200 (Regular, level 0) by default. So I
  type DIR /S (as an example of a CPU consuming process) in one window,
  then switch to the other, and while the background window runs I type
  the same in the other. What is immediately observable is that the
  background window stops immediately, and runs very slowly in bursts
  approximately 1 second appart (I guess this is what MAXWAIT=1 means).
  As I understand, this is the starvation priority boost, where a
  starved thread gets a little increase in priority, because otherwise
  it wouldn't run since a higher priority thread is consuming all the
  CPU timeslices.

  If I click on the desktop so that both windows become background, then
  they run equally fast and multitask very smoothly. So the preemptive
  multitasking is obviously there, but only when both of them are in the
  background, AND at the same priority (read on).

  As soon as you click on one of them, the other one virtually stops! It
  only runs by means of the starvation boost, and if I had set
  PRIORITY=ABSOLUTE, this boost wouldn't be present and it would be
  suspended untill the higher priority process finishes it's bussiness.

  This is to be expected, because foreground processes experience a
  priority boost to increase responsiveness to the user, but I think
  this boost is a little exagerated, since everything STOPS in the
  background! So, I thought that the foreground boost is simply too big,
  and that's the reason why most of the processes stop in the
  background... but it seemes that the problem goes WAY DEEPER than
  this, right down to the OS/2 task sheduler!

   Why?

  Well, I tried to quantitatively measure just how much is this
  foreground priority boost. I measured this by increasing the priority
  of the background window, to see when will it start to run at the same
  speed as the foreground process. But this turned out to be impossible!

  The priority at which foreground processes run seems to fall exactly
  between 0x41F (Foreground Server, level 32) and 0x300 (Time Critical,
  level 0).

  If you set the bg window to 0x300, it runs ok, while the foreground
  window is stopped (along with most of the operating system... I found
  out the hard way that running DIR /S at Time Critical priority isn't
  the smartest thing to do :))  So don't try this unless you have
  WatchCat od Process Commander installed which can bail you out of this
  type of situation - they run at 0x31F, the highest priority possible,
  and can interrupt any process running at any priority)


  But, if you set the bg window to 0x41F, it still doesn't get
  any CPU cycles, and it is JUST THE SAME as if you ran it at 0x200!!!

  So, if there is a higher priority process running, the actual priority
  of the lower priority process simply doesn't matter, all that matters
  is that it has a LOWER priority! The difference in priorities is not
  taken in consideration by the OS/2 sheduler!

  So I thought, this must be a special case only when foreground
  processes are concerned, it can't be that the difference in priorities
  is ignored!

  But unfortunately it is, as my next experiment shows... :((

  I reset the priority of both windows back to 0x200 and decided to try
  something else.

  Process Commander is a great tool for changing the priorities of
  processes on the fly, or you can write a simple program to do it -
  only thing to remember is that if you want to change the priority of
  some other process, your program must be it's parent!


  I set the first window at priority 0x200, the second at 0x201, and put
  them both in the background, so that the foreground boost wouldn't
  interfere with the measurements.

  Common sense would dictate that the second window should run only
  slightly faster than the first, but to my amazement it ran full speed,
  while the first (lower priority) window didn't run at all (save for
  the starvation boost and the cycles released by DIR /S when it reads
  the next directory)!

  The second process was only 1 level of priority higher (out of
  possible 128!!!), and it still got ALL THE CPU TIMESLICES!

  So, where one would expect each process to get it's fair share of CPU
  time PROPORTIONALY to its priority, the policy in effect here seems to
  be THE-HIGHER-PRIORITY-THREAD-GETS-ALL!!!

  It doesn't matter if the difference beetwen priorities is only 1, or
  10, or 50, or 100... only thing that matters to the scheduler is which
  one is HIGHER!

  This being the case, I really don't see the point in having 128
  different priority levels... they're all wasted for nothing!

  So, when processes have different priorities, the multitasking isn't
  preemptive anymore! The lower priority process only gets time slices
  when:

   1) it receives a priority boost due to its starvation, which is
   negligible for almost all purposes and I'll ignore it

   2) the higher priority process DECIDES TO RELEASE the CPU by calling
   DosSleep or almost any other API call (it seems, and it was mentioned
   here, that a context switch is forced after every API call (if there
   are waiting threads of course))

  Well, this doesn't sound to preemptive to me, it's more like the
  cooperative model of multitasking in Win 3.1...

  (I understand of course that the multitasking facilities of OS/2 are
  truly preemptive, and I am only asserting that this capability is very
  poorly used)

 The only way to have preemptive multitasking is when both threads run
 at EXACTLY the same priority.

   And it gets worse, but as this message turned out to be pretty long
   (I have this tendency to overexplain things) I'll continue in the
   next.

                                                            - Ivan -

.!. Nuke 'em 'til they glow, then shoot 'em in the dark!
--- Terminate 5.00/Pro [OS/2]
 þ TerMail/QWK þ