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

[Rich Felker <dalias@libc.org>]

On Thu, May 18, 2023 at 04:01:18PM +0200, Jₑₙₛ Gustedt wrote:
> Rich,
> 
> on Thu, 18 May 2023 09:29:05 -0400 you (Rich Felker <dalias@libc.org>)
> wrote:
> 
> > Of course call_once is exempt from any such requirements
> 
> it was, but isn't anymore. In C23, now we have
> 
>     Completion of an effective call to the `call_once` function
>     synchronizes with all subsequent calls to the `call_once` function
>     with the same value of `flag`.

That's fine because it's for the same value of flag. The old POSIX
requirement is independent of the value of flag (just like
"synchronizes memory" for mutex lock is independent of which mutex
it's called with, etc.). This is why POSIX (as written) requires full
seq_cst for everything.

> POSIX (for which the ISO 9945 instantiation is currently at NB ballot)
> also has updated all of this
> 
>       The pthread_once() and call_once() functions shall synchronize
>       memory for the first successful call in each thread for a given
>       pthread_once_t or once_flag object, respectively. If the
>       init_routine called by pthread_once() or call_once() is a
>       cancellation point and is canceled, a successful call to
>       pthread_once() for the same pthread_once_t object or to
>       call_once() for the same once_flag object, made from a
>       cancellation cleanup handler shall also synchronize memory.
> 
> If I understand this correctly, the C11 interfaces become mandatory if
> the platform supports threads.

Looks like POSIX is fixing it then, by making it specific to the
object, just like C11. So all should be good.

Rich