[musl] =?gb18030?B?UmU6UmU6IFJlOiBbbXVzbF0gUXVlc3Rpb26juldoeSBtdXNsIGNhbGwgYV9iYXJyaWVyIGluIF9fcHRocmVhZF9vbmNlPw==?=

[musl] =?gb18030?B?UmU6UmU6IFJlOiBbbXVzbF0gUXVlc3Rpb26juldoeSBtdXNsIGNhbGwgYV9iYXJyaWVyIGluIF9fcHRocmVhZF9vbmNlPw==?=

[=?gb18030?B?ODQ3NTY3MTYx?=]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="gb18030", Size: 525 bytes --]

Hi

>Besides it doesn't help your case. You wanted to remove the "dmb"
>instruction right? Well, that code adds it if the compiler thinks it is
>necessary, and GCC trunk for ARM does so: https://godbolt.org/z/WcrfTdTx5

I compared the implement between musl and bionic in assembly code, 
I see bionic don't generate 'dmb' with clang, you can also check in here,
https://godbolt.org/z/hroY3cc4d
So it has better performance in comman case which init function is done.

So can we do any optimization here? 

Chuang Yin

Re: [musl] Re:Re: Re: [musl] Question：Why musl call a_barrier in __pthread_once?

[Szabolcs Nagy]

* 847567161 <847567161@qq.com> [2023-05-22 09:53:05 +0800]:
> &gt;Besides it doesn't help your case. You wanted to remove the "dmb"
> &gt;instruction right? Well, that code adds it if the compiler thinks it is
> &gt;necessary, and GCC trunk for ARM does so: https://godbolt.org/z/WcrfTdTx5
> 
> I compared the implement between musl and bionic in assembly code, 
> I see bionic don't generate 'dmb' with clang, you can also check in here,
> https://godbolt.org/z/hroY3cc4d
> So it has better performance in comman case which init function is done.
> 
> So can we do any optimization here? 

we went over the options up thread but

1) arm != aarch64. clang generates dmb too on armv7-a.

2) the clang you use there is wrong for aarch64: it generates code for
the latest arch, which would not run on baseline -march=armv8-a cpu.
(ldapr is armv8.3-a and not implemented on most cpus currently in use)

3) ldar (or ldapr) are atomic instructions that have an acquire barrier
internally, so while it's not as strong as a dmb it is still a barrier.
(x86 is a different story, there normal loads are already acquire mo)

4) acquire barrier is not enough, posix requires 'synchronize memory'
for the first call in each thread. (bionic implements weak 'synchronize
memory', which arguably breaks some valid posix code, so musl is
conservative).

5) even if musl allowed weak 'synchronize memory', adding weak atomics
to musl would either be a maintenance burden (to implement on all
targets and update the synchronization code) or a regression if
compiler builtins were used for them (old compilers would not work,
even recent gcc/llvm had atomics bugs affecting abi on various targets).

6) the TLS solution would avoid the barrier completely and it guarantees
that in each thread for each once_flag there is a synchronize memory
either at the first pthread_once call *or* somewhere between that and
the once_function completion. (the *or*... bit is not posix conform,
but it is iso c conform. faster than the bionic code in the common case)

so call_once can be optimized to have no barrier or atomics at all
in the fast path (apart from relaxed mo atomics), to do the same for
pthread_once at least an accepted austingroupbugs report is needed to
relax the requirement. a posix relaxation is needed for using acquire
barrier as well (though most libc implementations already assume this
relaxation).

[musl] =?gb18030?B?UmU6UmU6IFJlOiBbbXVzbF0gUXVlc3Rpb26juldoeSBtdXNsIGNhbGwgYV9iYXJyaWVyIGluIF9fcHRocmVhZF9vbmNlPw==?=

[=?gb18030?B?ODQ3NTY3MTYx?=]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="gb18030", Size: 1386 bytes --]

How about the  implement of aosp£¿ Didn't they follow the posix£¿
http://aospxref.com/android-13.0.0_r3/xref/bionic/libc/bionic/pthread_once.cpp#41

> The problems happened back when GCC 6 and 7 were popular. The problem
> was due to something sideways in glibc.
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66146
>
> If you want a call_once-like initialization then rely on N2660:
> Dynamic Initialization and Destruction with Concurrency.

>That's the general algorithm we've been talking about (though without
>bad properties like gratuitously inlining it to lock-in implementation
>details as ABI).

So I can think you have a plan to optimize this, right?

> 1¡¢Can we move dmb after we get the value of control£¿ like this£º
>
> int __pthread_once(pthread_once_t *control, void (*init)(void))
> {
>     /* Return immediately if init finished before, but ensure that
>     * effects of the init routine are visible to the caller. */
>     if (*(volatile int *)control == 2) {
>         // a_barrier();
>         return 0;
>     }

>  writes in init may not be visible when *control==2, without
>  the barrier. (there are many explanations on the web why
>  double-checked locking is wrong without an acquire barrier,
>  that's the same issue if you are interested in the details)

yes, can you show me the web£¿

Re: [musl] Re:Re: Re: [musl] Question：Why musl call a_barrier in __pthread_once?

[Szabolcs Nagy]

* 847567161 <847567161@qq.com> [2023-05-18 22:37:06 +0800]:
> &gt;  writes in init may not be visible when *control==2, without
> &gt;  the barrier. (there are many explanations on the web why
> &gt;  double-checked locking is wrong without an acquire barrier,
> &gt;  that's the same issue if you are interested in the details)
> 
> yes, can you show me the web？

https://preshing.com/20130930/double-checked-locking-is-fixed-in-cpp11/

this links to papers that explain why you need the barrier
in the fast path.

Re: [musl] Re:Re: Re: [musl] Question：Why musl call a_barrier in __pthread_once?

[Markus Wichmann]

Am Thu, May 18, 2023 at 10:37:06PM +0800 schrieb 847567161:
> How about the  implement of aosp？ Didn't they follow the posix？
> http://aospxref.com/android-13.0.0_r3/xref/bionic/libc/bionic/pthread_once.cpp#41
>

Apparently not. If the initialization routine is cancelled, the control
variable is not reset to 0, so all future calls to pthread_once() on the
same variable will just hang. But that can be remedied with adding the
requisite pthread_cleanup_push()/pop() calls around the call to the
init routine.

Besides it doesn't help your case. You wanted to remove the "dmb"
instruction right? Well, that code adds it if the compiler thinks it is
necessary, and GCC trunk for ARM does so: https://godbolt.org/z/WcrfTdTx5

Ciao,
Markus