From owner-svn-src-projects@FreeBSD.ORG Tue Sep 18 12:15:04 2012 Return-Path: Delivered-To: svn-src-projects@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5B7231065670; Tue, 18 Sep 2012 12:15:04 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) by mx1.freebsd.org (Postfix) with ESMTP id ED02A8FC12; Tue, 18 Sep 2012 12:15:03 +0000 (UTC) Received: from c120.sec.cl.cam.ac.uk (c120.sec.cl.cam.ac.uk [128.232.18.120]) (authenticated bits=0) by theravensnest.org (8.14.5/8.14.5) with ESMTP id q8ICF0ST077916 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Tue, 18 Sep 2012 12:15:00 GMT (envelope-from theraven@FreeBSD.org) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: David Chisnall In-Reply-To: <20120918105323.GB37286@deviant.kiev.zoral.com.ua> Date: Tue, 18 Sep 2012 13:15:01 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201207301350.q6UDobCI099069@svn.freebsd.org> <201207301732.33474.jhb@freebsd.org> <505849DB.3090704@FreeBSD.org> <20120918105323.GB37286@deviant.kiev.zoral.com.ua> To: Konstantin Belousov X-Mailer: Apple Mail (2.1278) Cc: Davide Italiano , src-committers@FreeBSD.org, John Baldwin , Jeff Roberson , Dimitry Andric , attilio@FreeBSD.org, svn-src-projects@FreeBSD.org Subject: Re: svn commit: r238907 - projects/calloutng/sys/kern X-BeenThere: svn-src-projects@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the src " projects" tree" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 12:15:04 -0000 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=