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: OndÅej BÃlka <neleai at seznam dot cz>
- To: Carlos O'Donell <carlos at redhat dot com>
- Cc: Rich Felker <dalias at libc dot org>, Alexander Monakov <amonakov at ispras dot ru>, Samuel Thibault <samuel dot thibault at ens-lyon dot org>, Andreas Schwab <schwab at suse dot de>, libc-alpha at sourceware dot org
- Date: Thu, 3 Sep 2015 20:57:38 +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> <20150825125035 dot GA3463 at domone> <alpine dot LNX dot 2 dot 20 dot 1508251557030 dot 18864 at monopod dot intra dot ispras dot ru> <20150825143615 dot GH32742 at brightrain dot aerifal dot cx> <alpine dot LNX dot 2 dot 20 dot 1508311747010 dot 4709 at monopod dot intra dot ispras dot ru> <20150831145950 dot GX7833 at brightrain dot aerifal dot cx> <55E74AED dot 3040202 at redhat dot com>
On Wed, Sep 02, 2015 at 03:15:57PM -0400, Carlos O'Donell wrote:
> On 08/31/2015 10:59 AM, Rich Felker wrote:
> > On Mon, Aug 31, 2015 at 05:54:46PM +0300, Alexander Monakov wrote:
> >> On Tue, 25 Aug 2015, Rich Felker wrote:
> >>>> (however when libpthread is not linked in, you know that pthread_mutex_lock is
> >>>> not operating on shared memory: you'd need pthread_mutexattr_setpshared, which
> >>>> is not provided in libc.so.6)
> >>>
> >>> This is false. The process that maps and locks the process-shared
> >>> mutex need not be the one that called pthread_mutex_init. I ran into
> >>> this issue when optimizing static linking; you can't omit
> >>> process-shared code when the program doesn't reference
> >>> pthread_mutexattr_setpshared, because it could get the mutex from
> >>> another program -- that's the whole point of having it be
> >>> process-shared.
> >>
> >> As a result, a libc "stub" mutex must:
> >>
> >> - contain a full implementation for process-shared mutexes
> >> - for non-shared mutexes in single-threaded processes, modify them
> >> consistently with non-stub implementation (but modifications need not be
> >> atomic)
> >>
> >> Does Glibc do the former? (the bug report is about Glibc not doing the latter)
> >
> > I may be wrong, but my impression is that glibc does not support this
> > usage for process-shared mutexes (omitting -lpthread) and is relying
> > on the POSIX rule that you may need -lpthread to get pthread_*
> > functions, and interpreting this to mean that it's okay to have a
> > broken/non-conforming version of pthread_mutex_* in libc.so. If so, I
> > think this is technically correct, but risky since applications may be
> > assuming that, if the symbol exists (e.g. via configure checks) then
> > it works.
>
> Correct, we consider the test case invalid because you failed to
> link with -lpthread, and call it a QoI issue.
>
> The problem is that it's a dangerous QoI issue that we should fix.
>
Correct, we should handle process-shared mutex... separately from
optimizing atomics and nonshared mutexes.
We could theoretically use stubs and switch only when there is call of
mmap(...SHARED), or create thread which would probably be pointless as
that would always happen with process-shared mutexes.