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: Rich Felker <dalias at libc dot org>
- To: Carlos O'Donell <carlos at redhat dot com>
- Cc: Florian Weimer <fweimer at redhat dot com>, Andreas Schwab <schwab at suse dot de>, Samuel Thibault <samuel dot thibault at ens-lyon dot org>, libc-alpha at sourceware dot org
- Date: Wed, 2 Sep 2015 15:23:34 -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> <55E74931 dot 3070509 at redhat dot com>
On Wed, Sep 02, 2015 at 03:08:33PM -0400, Carlos O'Donell wrote:
> 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.
This usage case is not currently supported, but I think you could
support it with the approach you described. I'd like to see that
happen, but I'm more concerned about applications that never load
libpthread.so but nonetheless use the pthread_mutex_* functions for
process-shared mutexes and feel entitled to do so because the symbols
exist.
> 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.
This sounds like a reasonable direction for glibc.
Rich