Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!news.mel.connect.com.au!munnari.OZ.AU!news.ecn.uoknor.edu!paladin.american.edu!gatech!newsfeed.internetmci.com!vixen.cso.uiuc.edu!sdd.hp.com!hamblin.math.byu.edu!park.uvsc.edu!usenet
From: Terry Lambert <terry@lambert.org>
Newsgroups: comp.unix.bsd.netbsd.misc,comp.unix.bsd.bsdi.misc,comp.unix.solaris,comp.unix.aix
Subject: Re: ISP hardware/software choices (performance comparison)
Date: 16 Jan 1996 18:43:02 GMT
Organization: Utah Valley State College, Orem, Utah
Lines: 102
Distribution: inet
Message-ID: <4dgrjm$rnv@park.uvsc.edu>
References: <4cmopu$d35@vixen.cso.uiuc.edu> <4cu7t0$mg5@engnews2.Eng.Sun.COM> <4cv8j1$59k@park.uvsc.edu> <4d37d4$j0l@gremlin.backfire.mn.org> <DL29Az.Ax2@ftel.co.uk> <bryDL3r9p.2oq@netcom.com>
NNTP-Posting-Host: hecate.artisoft.com
Xref: euryale.cc.adfa.oz.au comp.unix.bsd.netbsd.misc:1993 comp.unix.bsd.bsdi.misc:2143 comp.unix.solaris:57430 comp.unix.aix:68851
bry@netcom.com (Bryan Althaus) wrote:
] The day I hear from someone who uses SunOS 4.1.3 and Solaris 2.5 on
] a regular basis and knows both OS's well and concludes that SunOS
] is better, is the day I give up UNIX and move to the NT camp.
I guess you will have to wait for 2.5 to have been out for
some time before you will listen to any argument whatsoever.
Of course this is not a fair comparison, since we should compare
4.1.3 with 2.x, where x is the level of release at the time that
4.1.3 developement was halted.
I say this because the developement fast that point could have
easily bein on either code base, and you are comparing unfairly
otherwise.
] The arguement I loved was the comparison of SunOS 4.1.x threads to
] Solaris 2.x. SunOS 4.1.x threads are a joke and Sun years ago told
] developers that they would no longer be supported and told our
] company not to use them. A few programmers wanted to use them and
] you can guess when deadline time came where all the problems were.
I see you have implicitly backed off from claim that LWP and
pthreads are the same thing.
Yes, people who use a facility that will be unsupported soon
are fools. Before you apply this to a 4.x to 5.x argument, let
me point out that buying fresh bread from a bad recipe will
result in your sandwich tasting worse than if you had used
day-old bread instead.
That you believe that LWP is a joke (it is no more so than the
idea that you can add more processors and multiply performance
on all problems regardless of their geometry) is irrelevant to
whether the 5.x/SVR4 threading mechanism is a joke.
Have you ever built and compared a threaded and non-threaded
version of an application? For instance, have you ever used
"team" or "ddd" for I/O interleaving on a device? (as an
aside, "team" fails on an MP Solaris box because of process
scheduling synchronization guarantees failing in the pipe
facility; "ddd", which uses shared memory, does not).
I have. I worked on the process architecture for the 4.x
NWU (NetWare for UNIX) product. It was *me* who implemented
interprocess decriptor table sharing system calls on AIX,
Solaris, SunOS, and UnixWare. It was *me* who implemented
the NWFS attributed file system. It was *me* who suggested
hot engine scheduling.
Because of the lack of process quantum guarantees and the
base code set being ill-adapted to a shared context model
because of a large amount of global data, sharing of context
on the work-to-do model via the SVR4 thread model was not an
option.
Nor was it a win over sharing global context in a shared memory
segment and sharing an open file table between the various
engines.
For one thing, if you use the idiotic SVR4 model, you must
preallocate the stack at thread creation time.
For another thing, using the SVR4 model precludes the ability
to attach a management utility to the context and manipulate
it. If it's a shared memeory segment and descriptor table,
I can attach and detach the thing at will.
It's IOTTMCO that n:m mapping for n != m for kernel vs. user
space threads means that some work-to-do engines (such a
model operates on engine anonymity) will suffer starvation
for process quantum.
Obviously, this is only true if the engines perform blocking
operations. Like I/O to talk to clients. Or file system I/O.
Like NetWare, Oracle, Sybase, Informix, etc., etc..
] When we ported to Solaris 2.4 and rewrote using real threads,
] the problems all went away. Wonder why?
Second system effect? Assumption that signals are events
instead of persistant conditions?
If you were truly clever, you would have implemented using
async I/O an completion routines. The aioread, aiowrite,
aiowait, and aiocancel facilities exist on both 4.x and 5.x
and on most other UNIX platforms as well. This would have
prevented you from orphaning a portion of your market.
You wouldn't get to claim "nifty threads in this product!",
but it is a very rare occurance where a problem can not be
solved as well (or better) using a different technique.
Terry Lambert
terry@cs.weber.edu
---
Any opinions in this posting are my own and not those of my present
or previous employers.