--- In Firebird-Architect@yahoogroups.com, Jim Starkey <jas@...> wrote:

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

I understand what you write. But what happens when a long running
request (a report query, for instance) gets a priority boost, thus
making other requests have to wait? That is exactly what I see happen
all the time in practice: when the server is busy with a long report,
simple updates have to wait a lot longer than when there is no report
query running. So if Windows (I don't know if **x systems do any
better) does anything with thread priorities, it is of little use. If
the VMS scheme were used, any request that takes only a few
milliseconds can be handled immediately, thus giving the users a much
more responsive experience.

Btw, I am not talking about locks here, the simple transactions do get
handled eventually (before the report is finished), it's only slow.