From owner-freebsd-threads@FreeBSD.ORG Fri Mar 16 00:37:28 2007 Return-Path: X-Original-To: freebsd-threads@freebsd.org Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 64B7216A402; Fri, 16 Mar 2007 00:37:28 +0000 (UTC) (envelope-from keramida@freebsd.org) Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36]) by mx1.freebsd.org (Postfix) with ESMTP id C08FF13C43E; Fri, 16 Mar 2007 00:37:27 +0000 (UTC) (envelope-from keramida@freebsd.org) Received: from kobe.laptop (host5.bedc.ondsl.gr [62.103.39.229]) (authenticated bits=128) by igloo.linux.gr (8.13.8/8.13.8/Debian-3) with ESMTP id l2G0PZgf016667 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 16 Mar 2007 02:25:41 +0200 Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.13.8/8.13.8) with ESMTP id l2G0PHrS027895; Fri, 16 Mar 2007 02:25:28 +0200 (EET) (envelope-from keramida@freebsd.org) Received: (from keramida@localhost) by kobe.laptop (8.13.8/8.13.8/Submit) id l2G0PG6C027798; Fri, 16 Mar 2007 02:25:16 +0200 (EET) (envelope-from keramida@freebsd.org) Date: Fri, 16 Mar 2007 02:25:16 +0200 From: Giorgos Keramidas To: Max Laier Message-ID: <20070316002515.GA66354@kobe.laptop> References: <45F906ED.8070100@aueb.gr> <200703151827.39963.max@love2party.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200703151827.39963.max@love2party.net> X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-3.765, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL 0.63, BAYES_00 -2.60) X-Hellug-MailScanner-From: keramida@freebsd.org X-Spam-Status: No Cc: freebsd-threads@freebsd.org, freebsd-arch@freebsd.org Subject: Re: Multithreaded qsort(3) X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2007 00:37:28 -0000 On 2007-03-15 18:27, Max Laier wrote: > On Thursday 15 March 2007 09:42, Diomidis Spinellis wrote: > > Greetings, > > > > I've added multhread support to our qsort implementation. You can see > > the code at and some > > performance figures at the end of this email. I propose to add it to > > our libc. I need your opinions on the interface, and also any comments > > you may have on the code. I see the following design dimensions: > > > > 1. Naming and availability > > -------------------------- > > - Option 1.1: Replace qsort with this implementation > > * Pros: Programs gain performance without any source code change; > > abstraction (number of processors/cores should be invisible, just as > > the CPU architecture or disk drive interface) > > * Cons: May confuse multithreaded programs; programs require linking > > with pthreads library; programs whose compare function is not thread > > safe will break > > > > - Option 1.2: Name it qsort_mt > > * Pros: POLA; programs can tune the call according to their need > > * Cons: Programs require source code changes; we violate abstraction; > > namespace polution > > > > My proposal: option 1.2: name it qsort_mt and make it available in a > > separate library (libc_mt). > > I'd suggest to name it qsort() and put it in a separate library (not > necessarily named libc_mt, as I don't believe there are that many > functions in libc, that can actually gain from multithreading). > > This approach, would allow LD_PRELOAD'ing the _mt version without the > need to recompile. > > That said, I'm not sure this really belongs in the base system. As > qsort_mt it's way too obscure and unportable for any real application > to use it. As a replacement for qsort it won't work (as you pointed > out yourself). I do think that we need efforts like this, but they > should be made outside of FreeBSD, otherwise they won't be much useful > in general. Does it make sense to put all the thread/performance-related functions of this sort in libmt.so and allow either explicit linking with -lmt or preloading the library whenever needed? This way we can keep generally useful MT-safe functions in libmt.so and let people choose when they use them :)