Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Wed, 17 May 2023 09:12:40 -0400
From: Rich Felker <>
To: NRK <>
Subject: Re: Question:Why musl call a_barrier in __pthread_once?

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&nbsp;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:
> 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...


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.