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: Florian Weimer <fweimer at redhat dot com>
- To: 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: Tue, 25 Aug 2015 09:19:28 +0200
- 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>
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.)
--
Florian Weimer / Red Hat Product Security