[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Thu, 18 May 2023 22:37:06 +0800
From: "847567161" <847567161@...com>
To: "musl" <musl@...ts.openwall.com>
Subject: Re:Re: Re: Question：Why musl call a_barrier in __pthread_once?
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？
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
