This is the mail archive of the
mailing list for the glibc project.
Re: Dummy pthread functions in libc considered harmful
- From: OndÅej BÃlka <neleai at seznam dot cz>
- To: Rich Felker <dalias at libc dot org>
- Cc: Samuel Thibault <samuel dot thibault at ens-lyon dot org>, Andreas Schwab <schwab at suse dot de>, libc-alpha at sourceware dot org
- Date: Tue, 25 Aug 2015 14:51:19 +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>
On Mon, Aug 24, 2015 at 12:22:50PM -0400, Rich Felker wrote:
> On Mon, Aug 24, 2015 at 05:38:16PM +0200, Samuel Thibault wrote:
> > Andreas Schwab, le Mon 24 Aug 2015 17:30:40 +0200, a écrit :
> > > BZ #18853 shows how the use of the dummy pthread functions in libc can
> > > be harmful if dlopen brings in libpthread by dependency.
> > I have to admit I've always wondered about this case, and never took
> > the time to report the issue, partly because I guessed people wouldn't
> > dlopen() while "owning" a mutex. This can be fixed by making the mutex
> > stubs really modify the mutex, possibly optimized into just not using
> > lock prefixes etc.
> > Not having proper stubs in libc makes applications write their own stubs
> > (see libpthread-stubs in freedesktop for instance), which will suffer
> > from the same issue.
> I agree that removing them would be a bad idea, but why not just put
> the actual code (real locking) in the ones in libc.so? The tiny
> performance gains (for programs doing dubious stuff to begin with)
> from omitting the lock prefix seem like they would be dwarfed by the
> maintenance cost of having to provide a separate version of the code
> and the risk of bugs from possibly invoking the wrong version of the
> function invoked (e.g. if a non-threaded program is using a
> process-shared mutex, where it would _seem_ to work but lack proper
While analysis that there are hardly performance gains I agree with that
we shouldn't use stub but full implementation.
Problem is that in many applications these are bottleneck as they use
pattern lock, do something trivial, unlock.
That is in shared library where half binaries that use it use threads
while other half dont.
As we internally already have SINGLE_THREAD_P optimization we should use
that optimization for all atomics and locks and get slower path only
when there is some thread created.
We could export that variable for gcc to also speed up atomics.