Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.carno.net.au!harbinger.cc.monash.edu.au!nntp.coast.net!news.sprintlink.net!news-peer.sprintlink.net!arclight.uoregon.edu!usenet.eel.ufl.edu!news.mathworks.com!newsfeed.internetmci.com!in1.uu.net!news.artisoft.com!usenet
From: Terry Lambert <terry@lambert.org>
Newsgroups: comp.unix.bsd.freebsd.misc,comp.unix.solaris,comp.os.linux.misc
Subject: Re: Benchmarking different Unix Operating Systems
Date: Fri, 13 Sep 1996 10:38:35 -0700
Organization: Me
Lines: 64
Distribution: inet
Message-ID: <32399C1B.7EC4FD4F@lambert.org>
References: <aak2.842008017@Isis.MsState.Edu> <50p41e$1ie@nnrp1.news.primenet.com> <5120jc$qh5@panix.com>
NNTP-Posting-Host: hecate.artisoft.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: Mozilla 2.01 (X11; I; Linux 1.1.76 i486)
Xref: euryale.cc.adfa.oz.au comp.unix.bsd.freebsd.misc:27231 comp.unix.solaris:82470 comp.os.linux.misc:129017
Bryan Althaus wrote:
] Not once they tried Solaris in an Ultra-Sparc ;^) Actually for
] me what seals the deal is SunSoft's Visual Worksop C++. I'm
] moving to HP-UX (again!) and am not looking forward to HP's
] SoftBench development system. I asked about it in comp.sys.hp.hpux
] and most repsonses were negative. Also from a programmers point
] of view, the lack of thread support is another minus.
From a systems engineering point of view, the SVR4/Solaris
threading model is broken.
The basic model is "bind N user space threads to M kernel space
threads".
If N > M, then (M - N) threads have CPU starvation, since any
blocking operation will block the kernel thread making it
unavailable to do real work.
Even if N == M, the CPU quantum is given away to another kernel
thread/process in the case of a blocking operation. That is a
potential process context switch overhead, and is minimally kernel
thread context switch overhead. Since you can't preferentially
give away the processor to kernel threads within your process
(since completion of blocking tasks by a thread before all other
threads in your process have run would starve other processes),
your own wins with kernel threading are:
1) SMP scalability
2) Competition for quantum of N threads a M processes with
other processes/kernel threads on the system
The first is a real win; the second is a pseduo-win, since the
same effect can be achieved with priorities.
In my opinion, once the scheduler gives me a quantum, it is *MY*
quantum; I should not have to be penalized for making a system
call, when another process could use up its full quantum without
penalty by not calling the system.
Probably the correct way (as opposed to the Solaris/SVR4 suggested
method of implementing a new scheduling class) would be to have
a cooperative scheduler in user space an convert all blocking
kernel calls to non-blocking calls plus a user space thread
context switch.
The gist of this is that your comparison is invalid: the lack
of Solaris/SVR4 threading is no great loss in the non-SMP case.
Its sole value for non-SMP lies in enabling the use of a more
complex architectural model, at the expense of increased context
switch overhead -- a loss which would not be there with the
pthreads model. Better to use a pthreads implementation and
consume your entire quantum, and achieve the same architectural
complexity in a POSIX-draft compliant way, without the overhead.
And pthreads runs on HP.
Regards,
Terry Lambert
terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.