Date: Tue, 18 Sep 2012 13:15:01 +0100 From: David Chisnall <theraven@FreeBSD.org> To: Konstantin Belousov <kostikbel@gmail.com> Cc: Davide Italiano <davide@FreeBSD.org>, src-committers@FreeBSD.org, John Baldwin <jhb@FreeBSD.org>, Jeff Roberson <jeff@FreeBSD.org>, Dimitry Andric <dim@FreeBSD.org>, attilio@FreeBSD.org, svn-src-projects@FreeBSD.org Subject: Re: svn commit: r238907 - projects/calloutng/sys/kern Message-ID: <E8EF9019-7E96-4A24-BAE4-F2C26DF126F8@FreeBSD.org> In-Reply-To: <20120918105323.GB37286@deviant.kiev.zoral.com.ua> References: <201207301350.q6UDobCI099069@svn.freebsd.org> <CAJ-FndBj8tpC_BJXs_RH8sG2TBG8yA=Lxu3-GTVT9Ap_zOCuVQ@mail.gmail.com> <CAJ-FndDnO7wjnWPV0tTu%2BUGHjsxa3YDarMxmyei3ZmjLAFvRkQ@mail.gmail.com> <201207301732.33474.jhb@freebsd.org> <CAJ-FndD5EO12xsWOAe6u0EvX00q33wxO4OivnGjzj0=T2Oe8uA@mail.gmail.com> <CAJ-FndCRg0UCThFkatp=tw7rUWWCvhsApLE=iztLpxpGBC1F9w@mail.gmail.com> <505849DB.3090704@FreeBSD.org> <EAB6CB55-C1A4-4099-AD86-6FDE3593A867@FreeBSD.org> <20120918105323.GB37286@deviant.kiev.zoral.com.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
On 18 Sep 2012, at 11:53, Konstantin Belousov wrote: > How can atomic_SIGNAL_fence be even remotely conceptually right for = the > kernel execution environment ? The fact that current implementation > happens to offer similar guarantees is a coincidense. atomic_signal_fence() is a barrier that enforces ordering with respect = to memory accesses within the same thread, but in the presence of = asynchronous events. The fact that it contains the word signal is = irrelevant. You may substitute interrupt for signal when reading it if = it makes you happier. > Agreed, but you did not looked at atomic.h. The memory clobbering is > only performed for atomics which do not need asm. The load acquire and > store release are implemented as the normal load and stores on x86, = due > to existing architecture guarantees. Ah, that makes sense, although, again, we have too strong a requirement = here. With a signal fence with an explicit acquire or release memory = ordering (or, better, an atomic_load_explicit() / = atomic_store_explicit() with an associated barrier), on x86 we will get = the single load or store instruction, and the compiler will be free to = reorder instructions except where doing so would conflict with the = barrier semantics. > Exactly which atomic operations for x86 do you reference there ? > Are you aware about e.g. AMD recommendations for the barrier/lock > prefix use (look into atomic.h) ? All of the operations that require inline assembly are, from the = perspective of the compiler, full barriers. They do not need to be = preventing reordering with respect to operations that do not touch = memory. Similarly, where we have acquire or release barriers, the = compiler should be free to either reorder stores or loads in one = direction across the barrier, but is prevented from doing so by the = memory clobber. =20 David=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E8EF9019-7E96-4A24-BAE4-F2C26DF126F8>