Dummy pthread functions in libc considered harmful

[Carlos O'Donell]

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.