Re: POSIX threads documentation

[Florian Weimer <fweimer at bfk dot de>]

* Carlos O'Donell:

> I assume you are talking about __libc_lock and associated functions
> which are used internally by the C library? These functions are
> pthread aware and become full locks when the pthread DSO is loaded,
> but they are not, AFAIK, available for use by library writers.

I need something like pthread_once, and if pthread is there, mutexes.

> Could you also please qualify the performance penalty you see when
> linking with pthreads?

Other libraries perform locking or atomic operations when they can
resolve certain symbols (such as pthread_create).  For instance,
std::string switches to atomic reference counts once
__gthread_active_p() detects the pthread_once symbol.  This incurs a
significant penalty on most processors (except the most recent round
of Intel CPUs, IIRC).

It also used to be the case that malloc() was *significantly* slower
once you linked to libpthread.  I think this has changed, though.

> Given your particular library how much of a
> penalty do you see? Why do you think there is a performance penalty?
> Is there anything the glibc community could do to help?
>
> Shared libraries are allowed to have undefined symbol references.
>
> Can you do this?
>
> if (pthread_mutex_lock != 0)
> {
>   /* OK, thread library is loaded so we need to use a threading
>      API to ensure correct handling of global data.  */
>   ...
> }

The comparison is always true because functions always have addresses.
The standard way to implement this check is to redeclare something in
libpthread as a weak symbol, and then check against that.  You cannot
use pthread_mutex_lock for this purpose because it is provided by
libc.  So even if I use this kludge, I need a symbol which is
guaranteed to be in libpthread, not libc.  pthread_once is one such
candidate, but without documentation, there is no guarantuee that it
remains in this state.

It's also difficult to come up with a prototype for pthread_once which
is guaranteed to be compatible with the official one.  This wasn't a
problem if you split your code into multiple translation units, but
you cannot reliably do that anymore thanks to LTO.

-- 
Florian Weimer                <fweimer@bfk.de>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99