Path: utzoo!utgpu!watmath!att!rutgers!ucsd!usc!samsung!uakari.primate.wisc.edu!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: <375@xyzzy.UUCP>
Date: 16 Nov 89 19:10:11 GMT
References: <6895@sybase.sybase.com> <2184@kodak.UUCP>
Sender: usenet@xyzzy.UUCP
Lines: 25

Although the Sybase approach does have it's merits, there are several problems 
with it:

1) A single server architecture cannot take DIRECT advantage of multiprocessor
hardware. By this I mean that the server threads cannot take advantage of an idle
processor since the server threads are bound to the process. Workarounds are
either 1) OS threads which can be dispatched across cpus, or 2) Improving the
Server architecture such that multiple (one per cpu usually) Sybase style
servers can service their threads. Shouldn't be too difficult. A bit of SHM,
a few semaphore locks & there your are! Option (2) would be a good alternative
for them until proper threads are available from kernel folk.

2) A single server process may not be able to compete successfully for cpu 
resources in a cpu bound environment. Cpu cycles are allocated & scheduled for
processes, not application threads. This is a more difficult problem than (1)
above. For this instance, one would want each thread to be considered equally
in competition for the systems cpu cycles. Priority scheduling won't help, although some systems allow scheduling parameters (quanta, etc) to be associated
with a process. This helps, but it is still hard to be fair unless the load is
consistent. Again, properly implemented threads & multi server architectures
are helps here.



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