Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!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.065511.16714@odi.com>
Date: 10 Nov 89 06:55:11 GMT
References: <24285@sequent.UUCP> <1205@unify.UUCP> <90211@pyramid.pyramid.com> <1989Nov7.223725.20327@odi.com> <90594@pyramid.pyramid.com>
Reply-To: dlw@odi.com
Organization: Object Design, Inc.
Lines: 60
In-Reply-To: eric@pyramid.pyramid.com's message of 9 Nov 89 23:45:07 GMT

In article <90594@pyramid.pyramid.com> eric@pyramid.pyramid.com (Eric Bergan) writes:

   In article <1989Nov7.223725.20327@odi.com> dlw@odi.com writes:
   >
   >(1) Yes, the homebrew thread packages may have to acquire new features
   >that will slow them down some amount; but how much?

	   Unclear, but remember that none of the OS developers set out
   to "slow down" the context switch time - it has happened as additional
   functionality was added. There is no reason to not expect threads
   packages (even home brew ones) to not suffer the same as more functionality
   is added.

If we are comparing a homebrew lightweight process package to a
builtin lightweight process package, the main reason I could see that
the homebrew one might be faster is that it can be specialized for the
database system.  The builtin one might have accreted lots of features
because it is trying to be a general-purpose utility.  If I use the
builtin one, therefore, I may pay for features that I do not need.
I understand what you've been saying about features "creeping back",
but since the homebrew system is being used in only one situation,
probably not all the features would creep back; some might have only
been needed by fundamentally different applications.

(Obviously the situation is very different when we're talking about
large-grain multiprocessors: in that case, the builtin one wins hands
down since it can use the true concurrency.)

I'm talking "could" and "might", of course.  I make no claims about
any real system.  Only metering will prove anything, one way or the
other.  I'm certainly not trying to impugn your software or anyone
else's.

	   One major problem with homebrew thread implementations is the
   lack of general purpose tools such as debuggers, profilers, code coverage
   suites, etc. Each thread implementer either has to burn resources developing
   (and maintaining) their own, or do without.

Yes, that's quite true.

	   One other clarification - I'm to a certain extent playing devil's
   advocate in this discussion. I think there are some advantages to 
   user-level threads, both as a programming model and for potential 
   application-specific performance tuning. But I do think that one should
   examine all the performance issues, and really understand why one feels
   user-level context switching is occuring more quickly. Many times, it is
   because functionality has been dropped, and some of that may come creeping
   back. (Honest, we really don't slow the clock every time we enter kernel
   mode...)

I agree 100%.  It's fun to talk about what causes might have what
effects, but nobody should confuse such talk with evidence of actual
metering.  As I said, I am *not* really a fan of homebrew threads.  I
would ideally like to see threads provided by the operating system, in
a portable way, with reasonable efficiency.  It's interesting to note
that in the OS/2 world, threads are part of OS/2, and work the same
way on every OS/2 machine.  I hope that threads get standardized
between all the different Unix versions.

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