Date: Sun, 16 Jun 2013 13:49:09 +0200 From: Ed Schouten <ed@80386.nl> To: Marius Strobl <marius@alchemy.franken.de> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r251782 - head/sys/sparc64/sparc64 Message-ID: <CAJOYFBAJboTo-RZ35ya6BJ7j1ygyF_8ErSRyDNbbhEaV2QjbcA@mail.gmail.com> In-Reply-To: <20130615125651.GH91573@alchemy.franken.de> References: <201306150821.r5F8Lst5089231@svn.freebsd.org> <20130615125651.GH91573@alchemy.franken.de>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Marius, 2013/6/15 Marius Strobl <marius@alchemy.franken.de>: > Semantically, this change is wrong; what we really need here is an > acquire variant. Using the release variant instead happens to also > work - albeit additionally wastes CPU cycles for the write memory > barrier - because in total store order, atomic operations implicitly > include the read memory barrier necessary for acquire semantics. In > other words, atomic(9) is in dare need of atomic_store_acq_<type>(). I personally dislike the idea of extending the existing atomic(9) API. My long-term goal would be that we could just use C11 atomics instead of using our own home-grown API. If we can't express this using the atomic(9) API, I'd just like us to use <stdatomic.h> instead. Reading up on the C11 standard (section 5.1.2.4), it seems that the abstract model of threads described does not allow stores to be a acquire operations. This does make sense, though. A load can of course not be a release operation. Because releases synchronize with acquires, a store being an acquire operation would have nothing to synchronize with. So I guess in this case we should solve it by using a relaxed store, followed by an acquire fence: http://80386.nl/pub/sparc64-atomic.txt Would that work for you? -- Ed Schouten <ed@80386.nl>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJOYFBAJboTo-RZ35ya6BJ7j1ygyF_8ErSRyDNbbhEaV2QjbcA>