[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: 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

[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