[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