Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!samsung!brutus.cs.uiuc.edu!apple!sun-barr!lll-winken!xanth!mcnc!rti!xyzzy!aquila.DG.COM!harrism
From: harrism@aquila.DG.COM (Mike Harris)
Newsgroups: comp.databases
Subject: Re: Client/Server processes and implementations
Keywords: Client Server Processes
Message-ID: <718@xyzzy.UUCP>
Date: 28 Nov 89 14:21:36 GMT
References: <936@anasaz.UUCP> <7114@sybase.sybase.com> <6895@sybase.sybase.com> <2184@kodak.UUCP> <375@xyzzy.UUCP> <510@xyzzy.UUCP>
Sender: usenet@xyzzy.UUCP
Lines: 45

In article <936@anasaz.UUCP>, john@anasaz.UUCP (John Moore) writes:
> In article <510@xyzzy.UUCP> harrism@aquila.DG.COM (Mike Harris) writes:
    [stuff about cpu allocation]
> 
> [much good stuff about Unix needing to grow up & provide a configurable
>  scheduler, better I/O facilities, etc]

I fully agree. However, many business, which are run by people that aren't
as technical as your group, Spec UNIX for "portability" and "open systems". 
It is pure Specmanship.  Our AOS/VS operating system has all of the OS process 
scheduling and I/O support you mentioned, including mirroring. We even have 
hardware to support it (mirroring & intelligent controllers). We can't sell
it as well now, because managers, etc are Spec'ing UNIX. If people won't 
buy our hardware because it doesn't run the OS they want (even if ours is
technically superior, or meets the requirements for reliable, high volume
TP) then we can't sell the machine. So, what do we do? We sell Unix boxes to
those that want them & we enhance our UNIX kernel so that it meets our needs.

We, in an effort to support High Volume TP, & driven by DG/SQL, which takes
advantage of all of these features, have been adding these to DG/UX.
> 
> [good stuff about proper OS scheduler, etc leading to threads]
> of precisely targetted scheduling algorithms. In addition, it

I heartily agree with the threads discussion & look forward to the time when
they are readily available [soon, I believe, from our kernel].

> we have found that lock contention consumes lots of CPU when
> you have a large number of very active processes. The single
> server (or few servers) is a good way to reduce the lock overhead.

Your threads will have to cooperate also. If they can be scheduled, 
concurrently, against multiple CPUs then that is the way to go.

Overhead is inescapable when processes or threads must cooperate. Typically
the price is worth the gain.

My interpretation (and responses) of some of the discussions was biased more 
towards what is widely commercially available.

> John Moore (NJ7E)           mcdphx!anasaz!john asuvax!anasaz!john

regards,
Mike Harris - KM4UL                      harrism@dg-rtp.dg.com
Data General Corporation                 {world}!mcnc!rti!dg-rtp!harrism
Research Triangle Park, NC


Brought to you by Super Global Mega Corp .com