sweiger@sequent.UUCP (Mark Sweiger) (11/11/89)
Dan Weinreb (dlw@odi.com) writes the following regarding multithreading
client/server DBMS architectures on Unix multiprocessor platforms:
(1) Every serious multiprocessor Unix vendor provides some way to run
truly concurrent threads within a single Unix process; however, the
details of how this work differ from one vendor to another.
(2) There are serious multiprocessor Unix vendors who do not provide
any way to run truly concurrent threads within a single Unix process.
If (1) is the case, it seems that it would not be very hard to provide
a small software layer that would hide the differences between the
various operating systems. Then porting would require writing a new
version of this layer, sort of like writing a new device driver for a
new kind of disk, but it would be pretty easy.
The Unix International (UI) threading standard, which is destined to become
part of the POSIX industry group Unix standard, implies that threading
on multiprocessors should be truly concurrent (that is, individual
threads can execute concurrently on each of the multiple processors).
This means that POSIX compliant vendors (Sequent is one of them)
will offer a standard form of concurrent threading when they
finally get finished implementing the feature. If RDBMS software
took advantage of UI standard multithreading on multiprocessors,
not only would it get concurrent thread execution and the
load balancing advantages of symmetric multiprocessor scheduling, but it
would also get shared memory mapping and shared file descriptors for free,
which is a benefit threads have over normal Unix processes.
Now, will multithreading implemenations actually adhere to the emerging
standards, or will they be homebrew? The trend seems to be a bit of both.
If a standard implementation offers some compelling advantages over
homebrew, it tends to get adopted. For example, the concurrently
executing threads of the UI standard for multiprocessors offer
a significant advantage over the non-concurrent threads of homebrew
implementations. So, as you pointed out, the real key in implementing
portable multithreading in RDBMS software is to isolate the threading
code (scheduling, thread creation, thread deletion, etc.). I have
personally witnessed a conversion from homebrew to OS/2 threads
on one RDBMS product, and it took one man about 6 months to do it.
After having done this port to OS/2, the implementor assures me
that the threading interface is even more isolated than before,
and next time it will be even easier to port to a different environment.
--
Mark Sweiger Sequent Computer Systems
Database Software Engineer 15450 SW Koll Parkway
Beaverton, Oregon 97006-6063
(503)526-4329 ...{tektronix,ogcvax}!sequent!sweiger