Multithreaded qsort(3)

Giorgos Keramidas keramida at freebsd.org
Fri Mar 16 00:37:28 UTC 2007


On 2007-03-15 18:27, Max Laier <max at 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 :)



More information about the freebsd-arch mailing list