Jim Starkey:

> 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.
>

Technology of threads control, implemented by Borland in interbase, was
'slightly' not-traditional - it is voluntary threads switching
(something similar to cooperative multi-tasking in windows3.1), and only
in vulcan that voluntarism has gone. Windows thread scheduler treats a
call to WaitForMultipleObjects, performed by voluntary thread scheduler
of firebird (which does not differ from interbase), as "thread is
inactive and it's priority should be increased". In fact this is active
thread, which is ready to run, but is delayed by voluntary thread
scheduler. Therefore threads, which were actually waiting for something,
do not have priority higher compared with threads, actively running
under control of voluntary firebird thread scheduler. As a result, under
high loads firebird 1.0 server might did not respond for minutes (!) to
trivial queries. Should mention, that I've never seen such effects in
linux, though this may mean that under normal circumstances windows
thread scheduler does it's job better.

Switching of priorities, mentioned initially, in most cases makes
firebird server much more responsive. And, answering your question, what
you see in firebird.conf is a typo - inactive thread certainly gets
higher priority. This parameter should be gone in firebird 3 (after
vulcan integration).