Re: Dummy pthread functions in libc considered harmful

[OndÅej BÃlka <neleai at seznam dot cz>]

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
> synchronization).
> 
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.