This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 2/2] Initialize tunable list with the GLIBC_TUNABLES environment variable
- From: Siddhesh Poyarekar <sid at reserved-bit dot com>
- To: Carlos O'Donell <carlos at redhat dot com>
- Cc: Andreas Schwab <schwab at suse dot de>, libc-alpha at sourceware dot org, roland at hack dot frob dot com, "Paul E. Murphy" <murphyp at linux dot vnet dot ibm dot com>, Andi Kleen <andi at firstfloor dot org>
- Date: Wed, 13 Jan 2016 08:57:25 +0530
- Subject: Re: [PATCH 2/2] Initialize tunable list with the GLIBC_TUNABLES environment variable
- Authentication-results: sourceware.org; auth=none
- References: <20160111111719 dot GA4183 at devel dot intra dot reserved-bit dot com> <mvmd1t81axj dot fsf at hawking dot suse dot de> <20160111144537 dot GA3334 at devel dot intra dot reserved-bit dot com> <5695BA23 dot 6080307 at redhat dot com>
On Tue, Jan 12, 2016 at 09:44:51PM -0500, Carlos O'Donell wrote:
> Not true if you link statically and dlopen, at which point you could
> have multiple threads, and you call dlopen which loads
> libc.so/libpthread.so's constructors?
A single load (and constructor call) does not matter since there's
nothing to race against. The case of concurrent constructor calls I
mentioned in the following paragraph; the load lock is sufficient to
protect it.
> > Even in case the constructors do get called in parallel in different
> > threads, they should get synchronized by the dynamic linker load lock,
> > so you'd never have concurrent calls to __tunables_init that race on
> > the value of initialized.
>
> Please include a concurrency note there then, that this is protected
> by the load lock?
OK.
Thanks,
Siddhesh