Path: utzoo!utgpu!utstat!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!uunet!odi!dlw
From: dlw@odi.com (Dan Weinreb)
Newsgroups: comp.databases
Subject: Re: Client/server model in popular portable relational databases
Message-ID: <1989Nov10.061329.16565@odi.com>
Date: 10 Nov 89 06:13:29 GMT
References: <24456@sequent.UUCP>
Reply-To: dlw@odi.com
Organization: Object Design, Inc.
Lines: 40
In-Reply-To: sweiger@sequent.UUCP's message of 6 Nov 89 23:48:11 GMT

In article <24456@sequent.UUCP> sweiger@sequent.UUCP (Mark Sweiger) writes:

		Now, if individual backend server threads could actually run
   on different CPUs of the multiprocessor *concurrently*, there would be no
   need for multiple server processes.  Since there is no easy way to achieve
   this functionality in a portable fashion,...

First, please temporarily stipulate that portability is not an issue;
pretend I'm designing a DBMS intended to run only on Sequent machines
under the Sequent operating system.  Sequent's version of Unix *does*
have a way to let me run multiple truly concurrent (i.e. can really
use separate CPUs at the same time) threads within a single Unix
process, right?

Second, let's return to reality; of course portability is an issue.
The state of the world might be one of two things:

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

I could be wrong about the "pretty easy" if the different vendors used
very different paradigms for their threads; but I'm having a hard time
seeing how they could do threads so differently that the port would
really be a problem.  I've seen a lot of thread packages, and they all
look pretty similar to me.

So are you saying that (2) is the case?  Or is there some other
mistake in my reasoning?  Thank you.

Dan Weinreb		Object Design, Inc.		dlw@odi.com