Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Thu, 18 May 2023 22:37:06 +0800
From: "847567161" <>
To: "musl" <>
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?

&gt; The problems happened back when GCC 6 and 7 were popular. The problem
&gt; was due to something sideways in glibc.
&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; 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.