This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Fwd: local equivalent for pthread_once() in glibc?
- From: Adhemerval Zanella <adhemerval dot zanella at linaro dot org>
- To: Florian Weimer <fweimer at redhat dot com>, libc-alpha at sourceware dot org
- Date: Wed, 17 May 2017 11:51:02 -0300
- Subject: Re: Fwd: local equivalent for pthread_once() in glibc?
- Authentication-results: sourceware.org; auth=none
- References: <9EBFE06E-AF1D-48E9-85AB-B74C048438B1@oracle.com> <F050C948-50BF-4305-84AC-9003F97D9F59@oracle.com> <be02ff5c-0313-29b2-e807-1a618559ec9c@redhat.com> <ff82b3b2-e282-9d88-775f-9fb46296787f@linaro.org> <d8588f17-b5b6-181d-2e97-7de012e89244@redhat.com>
On 17/05/2017 06:57, Florian Weimer wrote:
> On 04/26/2017 02:40 PM, Adhemerval Zanella wrote:
>> Now that we are on the subject, shouldn't we use __libc_once on
>> __malloc_initialized?
>
> I think that would be misleading. The arena selection code assumes that
> the main arena has been fully initialized, not just that ptmalloc_init
> has run. ptmalloc_init only performs a partial initialization, the rest
> is done through malloc_consolidate (which is again triggered by the
> allocation which is part of pthread_create). If we fix ptmalloc_init to
> allow concurrent invocation (although that never would happen), the lack
> of full initialization would still be in issue (in the impossible case
> that ptmalloc_init ran concurrenctly).
>
> Thanks,
> Florian
>
Right, but this is not seem the case for tunable where malloc_consolidate is
called from ptmalloc_init (at least for main_arena). In any case, I still
think that for adequate __malloc_initialized access using C11 atomic since
its access is still done concurrently (that why I asked if using __libc_once
would be simpler).