From nobody Mon May 31 11:23:04 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id D398DBFA31A for ; Mon, 31 May 2021 11:23:10 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic302-21.consmr.mail.gq1.yahoo.com (sonic302-21.consmr.mail.gq1.yahoo.com [98.137.68.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4FttFT1yLkz4cKB for ; Mon, 31 May 2021 11:23:08 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1622460187; bh=J5PNTbJdHb06fZeNfzn6nKujn/lXtbze7ZidXp2AK5g=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=Oq5f83i9zEwMJaEj90qFAzRlArTRTAwgGnEDuLQglhHrekCtUTmDUIpHunel2krSpfM1OmG8TqyRxL6p/0w3XjlEpVHKYzER0zFibqcoXhjNTsdUotLVykrhwQaWw80uk73iMPYZc4JZIVW9w1PuUdzi/T1MHUX7WsbgePLL2aaC7AsS0QTf3zw7Ja4rZfcjreQ9I9qQRQJjLzgRlt98/tQNEm0eoY9/y+4oI+hGml6mhnBl7tEdvnP9GstxAJuh3KdfK30yEzHzacI4sljkIDXlr+NDZymRhbeFt+uol+o0mNiAiXsugBWBbEJOOMiJ1VdQNs8u/fAOcEcpkoKofA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1622460187; bh=vekJRQcRT/uzryMqQRrjiDV3f0F5oCbA55K6iunzaka=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=hsvyC360Ro/8BYAK5bn+GC3FoYFiWumF7y/QWlj3jw6hevOobuLkZjPftFYGpLlnUkLLx60tATP7Z4uv6r4Itba6OjpE485xwFngLSFqfQr9xuZAWV70Srd2nxUOC8PyGj4SDeHhPalSEnZe93bHqf3GuxpLROOMmM2zVF52Abyg+GsUVqsBRA3ibDBHsxTJ+11+l2dPN5GTsrtYiE88LENnxY322MbwaQSyAhefTrMUJ3Cz6rjHvBeV5jIzbh+r7waBEMv3xz+mBf8/I9Ec8r2WJQAW765DTpo+T4W71ARsdrcLkPNuH5C2UYLWO60lqtfGiRknZDFkdI+wnj93/A== X-YMail-OSG: lEV20nwVM1lGgIhwDr.Z1c3BejetiM92EVaZckGhleNqCJtO8oR3lLWpQTHWUhl YQiArLEuQ3ju964lws0HyFEk8j8mhoY3YVNJV_FQV5lQoZIlEPSDim0zwBRwPFZuIypF7LjIahOd N4pOh3J1SnhB3IIRbAVeic7lGefX5EsLSOJ8L2IEzB30ZEeVCcmzAZ2N9nGjk3KbxKKnasznF0ln aiLkCELVQ66_F9qy5Kd2qDaq4a4g_JT2.Grhbzrqt7yAl3orCzuD2pgdy1Ey.uLKo3DX3uVXOyHK m.rAqv3IIJQ7Rrz6LYXWrg9Khb0S7iKJBGc61cd_gnMNLITk5Jn6Yv.lKfF.G0R90MsFZe4QsLKl 5U8lADuQH1NZ5fSQhsSjNEN8.7Kx52q41aHaNj6KfLZVHPqFDEcF83X8LRUipALDmlMc49BnKvq_ dfnIPwSX7UDblromoRxNQVaNvZQ5GQb506mRB85F4tgLVfD.Gc.E8k5941Bn_MMVyit9G6UwxTYo g0zvWqItKaBb.8kxIaXyXCNhZHwsn2oTMqtTsTxqpYZpb3wdgs3FU87jJQAv.C2Kcy893Fhcly3K Gweq63QkT7ZN08zbPohc6VGIVJ76SMc0_RfDCtS8HAEDK.lEWXkDnh4PcosCrsWISoIT6LDdTGYv hCPtQGUAtsKyjpuAJrSFNjfPBNCvC0mhzfCB1Fk8SaOZ1Rxd.UhD4H02vXut2nvcLzkHHVD749xu y7rXtY0Ksp8FUKmNLc.RgSkOm.WGKPnvF_paNikFOGTasqXXGWiK0QpXZNXG815rIkWE4CNLpLDJ nCUO4wKNrEh06wHPq3M2eIT3jXpIURNXQphUa7_W95TrM61sBLXdzqputo5m.yYwhHzcuqZ_OrOH R0WTqnH.3WMbubhE7qBExcSMY2Gd0NUeyOHi5Qqv5d1C.glHIoe53IY5XsuBZRWxiJsseQJBsXjq LZAvxzb8blOcvdmQtR2KafrvIAHbefNDIuIPH93D0g3YitSW_VrGE_EZI1Ni5SoEotz3Bg5RP22y La3IrHxsNOtt1PBABZhAo8nzSf.moptOjmw9VZqU0ars8T9IDnH0ZN6XLtFkEPpr.iXKM9JDMBZ5 iDFYyhYFifuxc9kv0QbQr4pQcETadtBllerC3k3LETy5VtLb0rFLGeCf9Iy479hoYcW4oV6Tk8vQ 1zefMC0LOOxMVOCzEshC5oXqSlrtKalkxkzN2ka6YJ5l0IugUuCR.eOqor5uOwUWtK5o7zdgqk87 FTpIJE0oXXRHdiYbPiA02OjJcVfMKmoXfI33q8CDg_.LngYVGemro011l5wRkDD1UNOtgs_dXkYN MPzHURUt7vCLRAPlsqr0Q1.JZyjBSUAn58czYMBeI5_F9.E_sX_gGWIkLrIV6u1DL.w.RTem7ImY 1kd1HI8ox5wAtUymXGNC1rpN1epMZKCZWnTAo2PWmHPz1cOApVxaKP6nCb.nkGfaGnFr.QE_BFyH AhuwSGv2lvf309PBkT99I7c5BIocU9xXMhs1XoahW_9m6uGtdX8IVnzJfwGBwe9V8GwFhl4hE1_N mufxDKkbcO9un23Ff9cwokBoUzSlmxxagoRc74fM7TkI6f4wUVAZm2M.zzaPaiujdtk8QKt.9H3T .UpCBZn2LZ54jxzIEypl0vbxTWCd8ZsK_HHYw4jskuroFLc4PnUHEZARragQYlbpOqsAWY0GOXP5 8z5Tj.9ue8Y5Q0G00sTg9kiP3GFlD5FDizPh37h1bKq6WiPcJ6D3qVXOOfr.S5DMwMWqtIrIsPve 86QV.OAe1T3gzEFjV_orKBQNp3fEfORrM6XsL.bzh46iFEJeyF6ckzz7WgZFL6Cl1ciYz.2k.Q3g V_XCONZz2eF8brzpCIAK9GrZRFv73feQ3KtMQq5xUeueLyi6NomGTRZAuQZZmcggD2KzpTkRPj6n 3aW9gzszt5bIc4aHwOPGF1ezJ7GcN0.jVRMaOAtRTOpYynWW3hUenzm.q2VyfLDNVuVJ6_FJaCBK uLpt.LvLju8rYuppMlzGX2C.F8h92V6KnclhbsyiqVhIRtbA7pvJlzORiKSnmRr3ewv4NPK1Siun nhDvWf9v2XUZpAQanCz7aMthQ5KvNv9ca6pLIJFY_Jjqx7.yIrP5i668jWDDAgnHCPczW8Fyfau5 F_Jo2GmkyzW9LWDXrifgPltS_9zJRLE5bDwfXJGbBCe6WRn3A.WU.dMvtAbxyxwXOXM0UNj8TSt. 8YNiq2iTBjDfXw0NH1fHhOEffZ7rKqowb8.lrzhH5Lgv8ebUSmuiqj1r7yBGYlWncaQpKj7N4Z0Z NNDK7FDxW02y99vhAanMzuzIr9_.5N2m9cZgmlARZ8Az49KaRPdIr8A9_9ZoHcrezG0U7ZLKSTBL EXkRdteaBhLdxCZRwIS0DQLLTei_lcnw_3cek_g5TfuU5i1gHkTPwPgirI9Eg7R6PGvMZPRSu2_n L7XQR6Fb4o87VfeO5lNtAqJoI6vskEALp2GycuyNpJPknoLxyLBtoYIaXFZyzu0XLgCvvTPnjxXx JwoMrZbde0Jfe9gSGv8cbFwXNyOiymTE39F2thYsJ9t5v.__L4KIYAI4vxaqU_L1YVoeklWwR5aV wXZ3H0gV7n5ouQOU8fT.3ud65QQ-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.gq1.yahoo.com with HTTP; Mon, 31 May 2021 11:23:07 +0000 Received: by kubenode568.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 22aa3df4465b3e865aa6fda3101562db; Mon, 31 May 2021 11:23:05 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.80.0.2.43\)) Subject: Re: Is powerpc64 atomic_load_acq_##TYPE omitting isync believed correct? In-Reply-To: <07D39D7F-711B-4FF3-AA33-AB691C231FA4@yahoo.com> Date: Mon, 31 May 2021 04:23:04 -0700 Cc: FreeBSD Hackers Content-Transfer-Encoding: 7bit Message-Id: <944F3A86-8EAA-42F5-A0BC-FF2BA8E480DA@yahoo.com> References: <07D39D7F-711B-4FF3-AA33-AB691C231FA4@yahoo.com> To: FreeBSD PowerPC ML X-Mailer: Apple Mail (2.3654.80.0.2.43) X-Rspamd-Queue-Id: 4FttFT1yLkz4cKB X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=Oq5f83i9; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.147 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-2.50 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RBL_DBL_DONT_QUERY_IPS(0.00)[98.137.68.147:from]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; SUBJECT_ENDS_QUESTION(1.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; SPAMHAUS_ZRD(0.00)[98.137.68.147:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.147:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.147:from]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-hackers] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-hackers X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N On 2021-May-29, at 23:04, Mark Millard wrote: > In the code from /usr/include/machine/atomic.h for powerpc64 > and powerpc there is: > > #define ATOMIC_STORE_LOAD(TYPE) \ > static __inline u_##TYPE \ > atomic_load_acq_##TYPE(volatile u_##TYPE *p) \ > { \ > u_##TYPE v; \ > \ > v = *p; \ > powerpc_lwsync(); \ > return (v); \ > } \ > \ > static __inline void \ > atomic_store_rel_##TYPE(volatile u_##TYPE *p, u_##TYPE v) \ > { \ > \ > powerpc_lwsync(); \ > *p = v; \ > } > > This code sequence does not involve isync: > > #define __ATOMIC_ACQ() __asm __volatile("isync" : : : "memory") > > What justifies this? All the reference material I've > found for C++/C11 semantics agrees with: > > https://www.cl.cam.ac.uk/~pes20/cpp/cpp0xmappings.html > > that shows (organized here to compare Relaxed vs. > Acquire and Release): > > powerpc Load Relaxed vs. Acquire: ld vs. ld;cmp;bc;isync > powerpc Fence: Acquire: lwsync > powerpc Store Relaxed vs. Release: st vs. "Fence: Release";st > powerpc Fence: Release: lwsync > > lwsync does not order prior stores vs. later loads, isync does > (and more in some respects). That likely (partially) explains > why load-acquire does not use just an acquire-fence in such > materials. > > Is this a problem for being correct for "synchronizes with" in > "man atomic"? For the acquire operation reading the value > written by the release operation: > > QUOTE > . . . the effects of all > prior stores by the releasing thread must become visible to subsequent > loads by the acquiring thread > END QUOTE > > It seems that some later loads could be moved by the hardware > to be too early relative to various such prior stores (as seen > in the load-acquire thread): no constraint is placed for such > relationships by the atomic_load_acq_##TYPE as far as I can see. > > > (I got into this by finding some code that uses an > atomic_store_rel_##TYPE without any matching use of > atomic_load_acq_##TYPE or atomic_thread_fence_acq or other such, > so far as I found. But, looking around to see if I could find a > justification for such code, generated more questions, such as > in this note.) Never mind. I figured out my significant confusion in interpretation. (Net result: lwsync is more than sufficient.) === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)