From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_LOW,RCVD_IN_MSPIKE_H2,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 10919 invoked from network); 23 May 2023 19:41:54 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 23 May 2023 19:41:54 -0000 Received: (qmail 16131 invoked by uid 550); 23 May 2023 19:41:50 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 16099 invoked from network); 23 May 2023 19:41:50 -0000 Date: Tue, 23 May 2023 21:41:38 +0200 From: Szabolcs Nagy To: 847567161 <847567161@qq.com> Cc: musl Message-ID: <20230523194138.GX3630668@port70.net> Mail-Followup-To: 847567161 <847567161@qq.com>, musl References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [musl] Re:Re: Re: [musl] =?utf-8?Q?Que?= =?utf-8?B?c3Rpb27vvJpXaHk=?= musl call a_barrier in __pthread_once? * 847567161 <847567161@qq.com> [2023-05-22 09:53:05 +0800]: > >Besides it doesn't help your case. You wanted to remove the "dmb" > >instruction right? Well, that code adds it if the compiler thinks it is > >necessary, and GCC trunk for ARM does so: https://godbolt.org/z/WcrfTdTx5 > > I compared the implement between musl and bionic in assembly code, > I see bionic don't generate 'dmb' with clang, you can also check in here, > https://godbolt.org/z/hroY3cc4d > So it has better performance in comman case which init function is done. > > So can we do any optimization here? we went over the options up thread but 1) arm != aarch64. clang generates dmb too on armv7-a. 2) the clang you use there is wrong for aarch64: it generates code for the latest arch, which would not run on baseline -march=armv8-a cpu. (ldapr is armv8.3-a and not implemented on most cpus currently in use) 3) ldar (or ldapr) are atomic instructions that have an acquire barrier internally, so while it's not as strong as a dmb it is still a barrier. (x86 is a different story, there normal loads are already acquire mo) 4) acquire barrier is not enough, posix requires 'synchronize memory' for the first call in each thread. (bionic implements weak 'synchronize memory', which arguably breaks some valid posix code, so musl is conservative). 5) even if musl allowed weak 'synchronize memory', adding weak atomics to musl would either be a maintenance burden (to implement on all targets and update the synchronization code) or a regression if compiler builtins were used for them (old compilers would not work, even recent gcc/llvm had atomics bugs affecting abi on various targets). 6) the TLS solution would avoid the barrier completely and it guarantees that in each thread for each once_flag there is a synchronize memory either at the first pthread_once call *or* somewhere between that and the once_function completion. (the *or*... bit is not posix conform, but it is iso c conform. faster than the bionic code in the common case) so call_once can be optimized to have no barrier or atomics at all in the fast path (apart from relaxed mo atomics), to do the same for pthread_once at least an accepted austingroupbugs report is needed to relax the requirement. a posix relaxation is needed for using acquire barrier as well (though most libc implementations already assume this relaxation).