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

[Rich Felker <dalias@libc.org>]

On Wed, May 17, 2023 at 05:17:28PM +0600, NRK wrote:
> On Wed, May 17, 2023 at 06:07:09PM +0800, 847567161 wrote:
> > Why musl add a_barrier() in if branch here?
> 
> It's explained in the comment:
> 
> | but ensure that effects of the init routine are visible to the caller.
> 
> > What happend if we remove it? Could you give me more details?
> 
> If you remove the barrier, then the calling code may not see the effects
> of the init function, especially on cpus with "relaxed" memory ordering.

Exactly. The whole purpose of pthread_once is to synchronize the
caller with the completion of the initialization function, which may
have happened in another thread.

> Which leads me to the question, are you familiar with cpu memory
> ordering? If not, I'd recommend reading this:
> https://research.swtch.com/hwmm
> 
> One more thing, what's the motivation behind trying to remove the
> barrier in the first place?

The barrier is expensive, and discourages use of
pthread_once/call_once where it would be a good primitive to do
thread-safe global init stuff.

There is an alternate algorithm for pthread_once that doesn't require
a barrier in the common case, which I've considered implementing. But
it does need efficient access to thread-local storage. At one time,
this was a kinda bad assumption (especially legacy mips is horribly
slow at TLS) but nowadays it's probably the right choice to make, and
we should check that out again...

Rich