Vlad Horsun wrote:

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

I did that the original design and implementation long before Borland
bought Ashton-Tate and Interbase for Interbase V3. It supported
threading on Apollo (native Apollo threads) and VMS (my own threading
package). It's quite likely that my threading package was the first
thread implementation on VMS -- it was certainly a year ahead of DEC's.
We wanted to use SunOS threads, but even their examples didn't compile.

We didn't screw around with thread priorities because I didn't approve
of them then, either.

>
> MS SQL have the similar approach and very happy with it.
> Google for 'user mode scheduler'
>
>

MS SQL derived from Sybase SQL Server which was designed around a
proprietary Sybase thread system. It isn't the least bit surprising
that it performs better with a voluntary scheduler than a general
purpose one, but I wouldn't generalize on this at all. There is a
trade-off with internal synchronization and mutexes versus parallelism
and read/write locks that Sybase and Microsoft took differently than I
did with Vulcan. If you take MS SQL Server's scheduler out of context,
you are likely to come to incorrect conclusions. A database system
design has to be studied as a system, not as a system of interchangeable
parts.