Date: Fri, 16 Mar 2007 02:25:16 +0200 From: Giorgos Keramidas <keramida@freebsd.org> To: Max Laier <max@love2party.net> Cc: freebsd-threads@freebsd.org, freebsd-arch@freebsd.org Subject: Re: Multithreaded qsort(3) Message-ID: <20070316002515.GA66354@kobe.laptop> In-Reply-To: <200703151827.39963.max@love2party.net> References: <45F906ED.8070100@aueb.gr> <200703151827.39963.max@love2party.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2007-03-15 18:27, Max Laier <max@love2party.net> 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 <http://people.freebsd.org/~dds/qsort_mt.c>; 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 :)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070316002515.GA66354>