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£¿