[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20230517131240.GO4163@brightrain.aerifal.cx>
Date: Wed, 17 May 2023 09:12:40 -0400
From: Rich Felker <dalias@...c.org>
To: NRK <nrk@...root.org>
Cc: musl@...ts.openwall.com
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 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
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.
