hanszorn2000 wrote:

> (this message was originally posted in Firebird-general. Sorry if it
> reaches you twice).
>
> Inspired by the apparent interest in VAX-VMS in this group, I was
> thinking of the following.
> One of the genial concepts of VAX-VMS is the idea of dynamic
> priorities, implemented in such a way that inactive users/ processes
> get an increase of priority, whereas active processes are lowered
> after some seconds of activity. Why is this genial? Because this is
> what gives users the impression of a fast responding system. Processes
> that require a little amount of cpu time to complete a users request
> will then be processed immediately, while procces that take longer
> will have to wait a little more, which won't be noticed as they take
> some time anyway.
>
> Within Firebird however this principle seems to be reversed, which
> i.m.h.o. is a bad idea. In the Firebird.conf file I read this:
>
> # ----------------------------
> # Settings for the thread scheduler (Windows Only)
> #
> # The wait time, in milli-seconds (ms), before the priority of:
> # - an inactive thread is reduced to 'Low', or
> # - an active thread is increased to 'High'
>
> So my question is this: hello Firebird guru's, do you have a good
> explanation for this, or is this the opening to a nice improvement?
>
>

While the VMS thread scheduler was written after my time (there's a
story here), it follows the same philosophy of the VMS process
scheduler. The problem addressed by the VMS scheduler was a saturated
CPU with a high priority process waiting on a resource held my a low
priority process. Since the low priority process never got scheduled,
the high priority process was effectively blocked. To fix this, the VMS
process scheduler tweaks low priority processes so they get scheduled
every one in a while, regardless.

There are cases where thread priorities are critical such as real time
applications. Database systems are among them, however. The general
rule for thread priorities is that 99 to 100% of the cases they make
things worse than better. Unless your application requires (absolutely
requires) that a high priority thread *always* preempts a low priority
thread, you will always be better off letting the operating system
handle the priorities dynamically. I ripped a great deal of poorly
thought out thread priority code from Vulcan, and I hope it stays out.
Setting all thread priorities equal inside a database system means that
all threads get scheduled and a resource held by a never scheduled low
priority thread won't block a high priority thread.