Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [thread-next>] [day] [month] [year] [list] 
Message-ID: <tencent_BA6EF0C4ED071F0A173FBBC169C4F3E4B10A@qq.com>
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

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

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

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

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

&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？

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.