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: Rich Felker <dalias at libc dot org>
- To: Florian Weimer <fweimer at redhat dot com>
- Cc: Alexander Monakov <amonakov at ispras dot ru>, OndÅej BÃlka <neleai at seznam dot cz>, 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 10:40:21 -0400
- 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> <55DC7DA5 dot 4060409 at redhat dot com>
On Tue, Aug 25, 2015 at 04:37:25PM +0200, Florian Weimer wrote:
> On 08/25/2015 03:01 PM, Alexander Monakov wrote:
> > On Tue, 25 Aug 2015, OndÅej BÃlka wrote:
> >> 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.
> >
> > It's not possible to use "current process is single-threaded" predicate to
> > optimize atomics: they might be operating on shared memory.
>
> Such mutexes must be marked as process-shared, and therefore, the
> optimization could be skipped for them, I think.
Yes, this seems like a valid optimization if you skip applying it to
process-shared mutexes.
Rich