This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Dummy pthread functions in libc considered harmful
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: Florian Weimer <fweimer at redhat dot com>, Andreas Schwab <schwab at suse dot de>, Samuel Thibault <samuel dot thibault at ens-lyon dot org>
- Cc: Rich Felker <dalias at libc dot org>, libc-alpha at sourceware dot org
- Date: Wed, 2 Sep 2015 15:08:33 -0400
- Subject: Re: Dummy pthread functions in libc considered harmful
- Authentication-results: sourceware.org; auth=none
- References: <mvmr3ms4sbj dot fsf at hawking dot suse dot de> <20150824153816 dot GC3210 at type dot bordeaux dot inria dot fr> <20150824162250 dot GD32742 at brightrain dot aerifal dot cx> <20150824162641 dot GH3210 at type dot bordeaux dot inria dot fr> <mvmbndv4zeh dot fsf at hawking dot suse dot de> <55DC1700 dot 6060905 at redhat dot com>
On 08/25/2015 03:19 AM, Florian Weimer wrote:
> On 08/25/2015 09:09 AM, Andreas Schwab wrote:
>> Samuel Thibault <samuel.thibault@ens-lyon.org> writes:
>>
>>> It's usually not programs which call pthread_mutex, but libraries which
>>> want to be thread-safe without actually bringing the libpthread
>>> dependencye.
>>
>> Does the reason for avoiding the dependency still exist? Surely the
>> overhead of libpthread has been greatly reduced since the days of
>> linuxthreads.
>
> It's the use of atomics. I think it's still costly even if the cache
> line containing the lock is not bouncing between CPUs. If we put the
> full implementation into libc.so.6, we may need to add a fast path for
> the no-threads-created case. This would actually benefit
> single-threaded programs which spuriously link against libpthread (which
> happens quite often).
>
> (Note: I do not fully understand the sysdeps overrides, someone more
> familiar with the code should check that the fast path is currently
> missing from the libpthread version.)
>
Is there ever a safe way to transition from running unthreaded to
threaded if you are not using a full implementation of locks in libc.so?
You would need to minimally use atomics to know that you have a
happens-after relationship between the loading of libpthread.so and
the running of the "optimized for no threads" lock case.
I think the only two viable solutions are:
(a) Use real locks in libc.so.6.
(b) Move all of libpthread into libc.
For now I think (a) is the most practical solution, with (b) to
be discussed in the long term, but I can't see it happening. It
would simply be easier to add libpthread.so to libc.so's AS_NEEDED
list.
Cheers,
Carlos.