Adding Priority Scheduling feature to the subprocess

[TimeHorse]

On Feb 21, 1:17 pm, Dennis Lee Bieber <wlfr... at ix.netcom.com> wrote:
>         Why imagine... AmigaOS ran -128..+127 (though in practice, one never
> went above +20 as the most time critical system processes ran at that
> level; User programs ran at 0, the Workbench [desktop] ran at +1... I
> think file system ran +5 and disk device handlers ran +10)
>
>         On the other side, VMS ran 0..31, with 16..31 being fixed realtime
> priorities, and 0..15 being variable (they don't drop below the process
> base, but can and are boosted higher the longer they are preempted)

Thanks for the info!  Actually, many peices of the WinNT kernel were
based on VMS, interestingly enough (go back to the NT 3.5 days and you
can see this) and of course Windows 2000, XP and Vista are all derived
from NT.  So I guess one long-time holdover from the VMS days of NT is
just as you say, it's still true in Windows: processes run 0..15 for
anything but realtime, even if the thread is boosted to Time Critical,
but in realtime the priorities go from 16..31.

Anyway, on the one hand AmigaOS support where -128 -> p = 0.0 and +127
-> p = 1.0 would be a good example of why simply using a 41 point UNIX
scale is defecient in representing all possible priorities, but apart
from the support AmigaOS argument, you bring up another issue which
may be dangerous: are priorities linear in nature?  For instance, a
with-Focus Windows App running Normal-Normal runs at priority 9, p ~=
0.29 (as well as likely for VMS), where as UNIX and Amiga have 0 for
normal processes, p ~= 0.50.  In many ways, the "Normal" mode being
the epoch makes sense, but this clearly cannot be done on a linear
scale.  Perhaps I should modify the PEP to instead having the generic
priorities from 0.0 to 1.0, to have them go from -1.0 to +1.0, with
0.0 considered normal priority.  Then, the negative and positive
regions can be considered linearly but not necessairily with the same
spacing since on Windows -1.0 to 0.0 spans 0 to 9 priorities and 0.0
to +1.0 spans 10 to 31 priorities.  And then, since +20 is the highest
AmigaOS priority in practice, yet the scale goes up to +127, the would
mean that from p ~= +0.16 to p ~= -1.0 you get obscenely high
priorities which do not seem practical.

I will need to think about this problem so more.  I'd hate to think
there might be a priority scale based on a Normal Distribution!  I'm
already going bald; I can't afford to loose any more hair!  :)

Anyway, thanks for info Dennis; you've given me quite a bit to think
about!

Jeffrey.