Path: utzoo!attcan!uunet!samsung!usc!apple!mips!prls!pyramid!eric
From: eric@pyramid.pyramid.com (Eric Bergan)
Newsgroups: comp.databases
Subject: Re: Client/server model in popular portable relational databases
Message-ID: <92258@pyramid.pyramid.com>
Date: 24 Nov 89 04:46:42 GMT
References: <24456@sequent.UUCP> <13520002@hpisod2.HP.COM>
Reply-To: eric@pyramid.pyramid.com (Eric Bergan)
Organization: Pyramid Technology Corp., Mountain View, CA
Lines: 33

In article <13520002@hpisod2.HP.COM> dhepner@hpisod2.HP.COM (Dan Hepner) writes:
>From: eric@pyramid.pyramid.com (Eric Bergan)
>> 
>> 	Actually, there are a number of standards efforts underway to
>> try and define a standard UNIX thread API. POSIX, UI, and OSF all
>> have groups meeting on this, and they actually are trying to converge
>> on a single standard. Further, since there are several reasonable models
>> to look at, its reasonable to assume that we can probably define a
>> useful standard. []
>
>Do any of these standards imply any given multiple processor shared
>memory data cache behavior?

	This is probably the source of the most active discussions within
the various standards committee's - what type of architecture to assume.

	The most conservative approaches tend to assume homogeneous processors,
shared memory system (almost certainly using a bus) with a moderate (1-30)
number of processors.

	The other end of the spectrum is heterogeneous processors, no
assumptions about memory access (read "message passing"), tons of processors
using a variety of interconnects.

	From what I have seen, most of the comittees have been trying to
define an interface and a model for threads that is independent of
implementation issues. But there are almost always some kind of 
underlying architectural assumptions which influence the specifications.

-- 

					eric
					...!pyramid!eric