This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH 2/2] Initialize tunable list with the GLIBC_TUNABLES environment variable
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: Siddhesh Poyarekar <sid at reserved-bit dot com>, Andreas Schwab <schwab at suse dot de>
- Cc: 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: Tue, 12 Jan 2016 21:44:51 -0500
- 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>
On 01/11/2016 09:45 AM, Siddhesh Poyarekar wrote:
> On Mon, Jan 11, 2016 at 02:51:36PM +0100, Andreas Schwab wrote:
>> Siddhesh Poyarekar <firstname.lastname@example.org> writes:
>>> __tunables_init (char **envp)
>>> - /* Empty for now. */
>>> + static bool initialized = false;
>>> + if (__glibc_likely (initialized))
>>> + return;
>> Is this supposed to be thread-safe?
> This is called only from the libc.so and libpthread.so constructors.
> So the first run will always happen exclusively in the main thread
> through either library constructor.
Not true if you link statically and dlopen, at which point you could
have multiple threads, and you call dlopen which loads
You can write a simple static test case that creates N threads and
calls dlopen on some DSO to test this.
> 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?