Re: Re: [musl] Question：Why musl call a_barrier in __pthread_once?

[Szabolcs Nagy <nsz@port70.net>]

* 847567161 <847567161@qq.com> [2023-05-18 10:49:44 +0800]:
> &gt; There is an alternate algorithm for pthread_once that doesn't require
> &gt; a barrier in the common case, which I've considered implementing. But
> &gt; it does need efficient access to thread-local storage. At one time,
> &gt; this was a kinda bad assumption (especially legacy mips is horribly
> &gt; slow at TLS) but nowadays it's probably the right choice to make, and
> &gt; we should check that out again...
> 
> 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)

> 2、Can we use 'ldar' to  instead of dmb here? I see musl
> already use 'stlxr' in a_sc.  like this:
> 
> static inline int load(volatile int *p)
> {
> 	int v;
> 	__asm__ __volatile__ ("ldar %w0,%1" : "=r"(v) : "Q"(*p));
> 	return v;
> }
> 
> if (load((volatile int *)control) == 2) {
>     return 0;
> }

i think acquire ordering is enough because posix does not
require pthread_once to synchronize memory, but musl does
not have an acquire barrier/load, so it uses a_barrier.

it is probably not worth optimizing the memory order since
we know there is an algorithm that does not need a barrier
in the common case.