Date: Thu, 12 Mar 2020 10:08:18 +0200 From: Andriy Gapon <avg@FreeBSD.org> To: src-committers@freebsd.org Cc: svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r358733 - head/sys/sys Message-ID: <2de9469e-591a-f9ff-b1ed-ffdd39ee4335@FreeBSD.org> In-Reply-To: <0d1145b3-1c29-aa21-1bd5-1129fdb88144@rice.edu> References: <202003080022.0280MX9j055805@repo.freebsd.org> <CAGudoHE4hTN5niCAsA4tfggywkEnGxiaoPz=rTX3AHA=fgZfkQ@mail.gmail.com> <20200309213512.GS98340@kib.kiev.ua> <CAGudoHHxRvrABfNThT=9_bv1dXsSExKrnFTScrHBDY1Z6GzGgg@mail.gmail.com> <20200310192326.GC1992@kib.kiev.ua> <CAGudoHFfHkaT9zTYyyj%2B8toGp7eYVwf5ECfKs-xTdTJUMwy4YA@mail.gmail.com> <0d1145b3-1c29-aa21-1bd5-1129fdb88144@rice.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On 12/03/2020 09:48, Alan Cox wrote: > Just to be clear, this is not just a matter of whether our release fences are > poorly or inefficiently implemented. Release fences (as defined by the C/C++ > standards that inspire our atomics) have *different* semantics than release > stores. Specifically, a release fence places more ordering restrictions on the > nearby store accesses than a release store does. (In fact, "man 9 atomic" > describes this.) Thus, it is almost inevitable that a release fence will have a > higher cost than the best possible implementation of a release store. For people like me who are new to these things here is a good explanation (perhaps a bad title, though): https://preshing.com/20131125/acquire-and-release-fences-dont-work-the-way-youd-expect/ -- Andriy Gapon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2de9469e-591a-f9ff-b1ed-ffdd39ee4335>