Re: Fwd: local equivalent for pthread_once() in glibc?

[Carlos O'Donell <carlos at redhat dot com>]

On 06/26/2017 09:12 AM, Adhemerval Zanella wrote:
> 
> 
> On 26/06/2017 09:51, Florian Weimer wrote:
>> On 06/26/2017 02:13 PM, Adhemerval Zanella wrote:
>>>
>>>
>>> On 25/06/2017 12:46, Florian Weimer wrote:
>>>> On 05/17/2017 04:51 PM, Adhemerval Zanella wrote:
>>>>> 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).
>>>>
>>>> I don't understand.  The concurrent access solely consists of reads.  We
>>>> do not use atomics in that case.
>>>
>>> My understanding and my point is even for these cases we should aim for 
>>> C11 atomic accesses, even for relaxed loads which on most architectures
>>> will map to normal loads.
>>
>> I don't think this is true.  If the last write happen before all the
>> concurrent read accesses, we don't need atomics.  To me, this is quite
>> clear because this is what happens with locks, where we usually don't
>> use atomics within the critical section, either.
> 
> I do agree with your rationale, but from Torvald comment on BZ #20822 [1]
> fix my understanding is to still use atomic relaxed MO for such cases
> simply for consistency (and I will add to add more readability to state
> the variable is indeed read concurrently and relaxed MO is suffice).
> 
> [1] https://sourceware.org/ml/libc-alpha/2016-12/msg00820.html
 https://sourceware.org/glibc/wiki/Consensus#Standards_we_use
https://sourceware.org/glibc/wiki/Concurrency

If there is no data race then we need to document why we have a happens-before.

-- 
Cheers,
Carlos.