Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 5 May 2003 15:08:05 +0200
From:      Alexander Leidinger <Alexander@Leidinger.net>
To:        Wesley Morgan <morganw@chemikals.org>
Cc:        cvs-all@freebsd.org
Subject:   Re: cvs commit: src/lib/libpthreadMakefilesrc/lib/libpthread/thread thr_attr_get_np.c thr_attr_init.c thr_attr_setcreatesuspend_np.c
Message-ID:  <20030505150805.6f56bb1c.Alexander@Leidinger.net>
In-Reply-To: <20030418113144.K93085@volatile.chemikals.org>
References:  <Pine.GSO.4.10.10304180221230.4419-100000@pcnet1.pcnet.com> <20030418113144.K93085@volatile.chemikals.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 18 Apr 2003 11:34:59 -0400 (EDT)
Wesley Morgan <morganw@chemikals.org> wrote:

> Ok, I'm a but confuzzled by all these threading libraries. Now we have
> libc_r, libthr, and libpthread? How can I alter the behavior of "-pthread"

Yes.

> to use a different library? As far as I can tell, only libc_r is actually

There's no official way to alter the behavior at compile time. Either
you replace libc_r by e.g. libthr, or you link against one of it by
hand. (... or you modify the binary by hand (s/libc_r/libthr/))

> linked in with a buildworld, so when is it planned to make these
> available? What are the advantages and disadvantages? Which library is
> more complete? Can someone do a summary of some sort to help out the
> consumers?

All of those libs are supposed to implement the POSIX Thread API.

libc_r works completely in userland, so you don't get a benefit from
more than one CPU in _one_ program (e.g. a program with 2 independent
threads doesn't use 2 CPUs at the same time, even if it could).

libthr and libpthread are based upon the KSE framework in the kernel.
libthr uses a 1:1 model, every POSIX thread is mapped to a kernel
thread, the threads in the example program above could run on 2 CPUs at
the same time. libpthread uses a M:N model (not as easy to implement as
a 1:1 model), think of it as of a combination of libthr and libc_r. Not
every POSIX thread is a kernel thread, M POSIX threads are mapped into N
kernel threads. The rationale behind this is, that there are a lot of
programs with threads which aren't independent, so you don't need to
have a kernel thread for every POSIX thread (crossing the barrier
between the userland an the kernel is expensive).

libc_r is widely tested but doesn't deliver the max. performance, libthr
and libpthread aren't widely tested but are supposed to perform better
than libc_r on SMP machines.

Bye,
Alexander.

-- 
   If Bill Gates had a dime for every time a Windows box crashed...
                ...Oh, wait a minute, he already does.

http://www.Leidinger.net                       Alexander @ Leidinger.net
  GPG fingerprint = C518 BC70 E67F 143F BE91  3365 79E2 9C60 B006 3FE7



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030505150805.6f56bb1c.Alexander>