Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 17 May 2023 20:11:31 +0800
From: "847567161" <847567161@...com>
To: "musl" <musl@...ts.openwall.com>
Subject: Re: Question:Why musl call a_barrier in __pthread_once?

Hi,

&gt; If you remove the barrier, then the calling code may not see the effects
&gt; 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);
}

&gt; One more thing, what's the motivation behind trying to remove the
&gt; 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

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.