[musl] =?gb18030?B?UXVlc3Rpb26juldoeSBtdXNsIGNhbGyBMIQyYV9iYXJyaWVyIGluIF9fcHRocmVhZF9vbmNlPw==?=

[musl] =?gb18030?B?UXVlc3Rpb26juldoeSBtdXNsIGNhbGyBMIQyYV9iYXJyaWVyIGluIF9fcHRocmVhZF9vbmNlPw==?=

[=?gb18030?B?ODQ3NTY3MTYx?=]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="gb18030", Size: 527 bytes --]

Hi,

Why musl add a_barrier() in if branch here?  
What happend if we remove it? Could you give me more details?

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;
	}
	return __pthread_once_full(control, init);
}

https://gitee.com/openharmony/third_party_musl/blob/master/src/thread/pthread_once.c#L44


Chuang Yin

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

[alice]

On Wed May 17, 2023 at 12:07 PM CEST, =?gb18030?B?ODQ3NTY3MTYx?= wrote:
> Hi,
>
> Why musl add a_barrier() in if branch here?  
> What happend if we remove it? Could you give me more details?

see commit df37d3960abec482e17fad2274a99b790f6cc08b,
removing it would cause issues on weakly-ordered memory models.

>
> 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;
> 	}
> 	return __pthread_once_full(control, init);
> }
>
> https://gitee.com/openharmony/third_party_musl/blob/master/src/thread/pthread_once.c#L44
>
>
> Chuang Yin

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

[NRK]

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.

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?

- NRK

=?gb18030?B?UmU6IFttdXNsXSBRdWVzdGlvbqO6V2h5IG11c2wgY2FsbIEwhDJhX2JhcnJpZXIgaW4gX19wdGhyZWFkX29uY2U/?=

[=?gb18030?B?ODQ3NTY3MTYx?=]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="gb18030", Size: 1108 bytes --]

Hi,

> 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.

Why musl add a_barrier in if branch? 
Can we call it after we get the control value If it want to init routine are visible to the caller?
just like:

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;
	}

        a_barrier();
	return __pthread_once_full(control, init);
}

> One more thing, what's the motivation behind trying to remove the
> barrier in the first place?

I'm analyzing pthread_once performance.
I found musl use dmb instruction£¬it will reduced performance  from 2.9ns to  6.9ns in some cases.

One more thing,  can we use some other instructions to ensure that 
effects of the init routine are visible to the caller? just like 'ldar' ...¡¯? 
As far as I know, 'dmb' has low performance.


Chuang Yin

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

[Rich Felker]

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

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

[Rich Felker]

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

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

[Jₑₙₛ Gustedt]

[-- Attachment #1: Type: text/plain, Size: 1448 bytes --]

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`.

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.


Thanks
Jₑₙₛ

-- 
:: ICube :::::::::::::::::::::::::::::: deputy director ::
:: Université de Strasbourg :::::::::::::::::::::: ICPS ::
:: INRIA Nancy Grand Est :::::::::::::::::::::::: Camus ::
:: :::::::::::::::::::::::::::::::::::: ☎ +33 368854536 ::
:: https://icube-icps.unistra.fr/index.php/Jens_Gustedt ::

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]