From owner-freebsd-threads@FreeBSD.ORG Mon Apr 21 20:25:39 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1074637B404 for ; Mon, 21 Apr 2003 20:25:39 -0700 (PDT) Received: from haldjas.folklore.ee (Haldjas.folklore.ee [193.40.6.121]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8455C43FAF for ; Mon, 21 Apr 2003 20:25:37 -0700 (PDT) (envelope-from narvi@haldjas.folklore.ee) Received: from haldjas.folklore.ee (localhost [127.0.0.1]) by haldjas.folklore.ee (8.12.3/8.11.3) with ESMTP id h3M3PaUE033209; Tue, 22 Apr 2003 06:25:36 +0300 (EEST) (envelope-from narvi@haldjas.folklore.ee) Received: from localhost (narvi@localhost)h3M3PZxi033206; Tue, 22 Apr 2003 06:25:36 +0300 (EEST) Date: Tue, 22 Apr 2003 06:25:35 +0300 (EEST) From: Narvi To: Terry Lambert In-Reply-To: <3EA49134.71A5BDC8@mindspring.com> Message-ID: <20030422060235.Y33034-100000@haldjas.folklore.ee> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: threads@freebsd.org Subject: Re: libkse -> libpthreads X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2003 03:25:39 -0000 On Mon, 21 Apr 2003, Terry Lambert wrote: > Narvi wrote: > > On Mon, 21 Apr 2003, Geoffrey C. Speicher wrote: > > > What's not clear about it? libkse is a superset of the functionality > > > of libthr. Seems pretty straightforward to me that the long-term > > > winner is libkse. > > > > This assumes that libkse M:N model will provide supperior performance and > > scalability, and this is not clear. Or does merely the fact that itis M:N > > somehow make it more winning contender? > > See other discussion. Performance should be identical, after > the upcall is eliminated in the case where all threads are > created PTHREAD_SCOPE_SYSTEM, and libkse communicates this to > the kernel to avoid generation of upcalls on blocking operations. > > Jeff makes a good point about the potential for bugs because of > the more sophisticated and larger total number of lines of code, > however. > Unless something went inheremtly wrong in case of the solaris threading libraries (or the published information is wrong), there is the potential for the additional code and complexity to add sufficent overhead to be measurable as perfomance degradation. It could be such might happen only with large values of M and N (and thus not surface in the next K years in a serious way in FreeBSD) or it could show up also on relatively small values of M and N or not at all. There are some unknowns in the picture, and say assigning a non-trivial likelyhood to at some point all processorts being 8-way (or even 4-way) EV8 style SMT would change some aspects of it. > Daniel also makes a good point about not finding them unless the > code is put in production. > > To my mind, it comes down to bug avoidance vs. bug detection, if > you weigh these arguments against each other. > I prefer bug avoidance and spending the saved time on perfomance - but this is for the moment a preference of somebody without time to spend on either thread library. > -- Terry >