From owner-freebsd-hackers@FreeBSD.ORG Tue Sep 29 17:53:39 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A639B1065670 for ; Tue, 29 Sep 2009 17:53:39 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by mx1.freebsd.org (Postfix) with ESMTP id 4F8288FC0A for ; Tue, 29 Sep 2009 17:53:39 +0000 (UTC) Received: from vampire.homelinux.org (dslb-088-067-228-142.pools.arcor-ip.net [88.67.228.142]) by mrelayeu.kundenserver.de (node=mreu2) with ESMTP (Nemesis) id 0MSVpQ-1MkxgI13MC-00RrzR; Tue, 29 Sep 2009 19:53:34 +0200 Received: (qmail 15651 invoked from network); 29 Sep 2009 17:53:34 -0000 Received: from kvm.laiers.local (HELO kvm.localnet) (192.168.4.200) by router.laiers.local with SMTP; 29 Sep 2009 17:53:34 -0000 From: Max Laier Organization: FreeBSD To: freebsd-hackers@freebsd.org Date: Tue, 29 Sep 2009 19:53:36 +0200 User-Agent: KMail/1.12.1 (Linux/2.6.30-ARCH; KDE/4.3.1; x86_64; ; ) References: <20090924224935.GW473@gandalf.sssup.it> <3bbf2fe10909290839w305c85c3t1532bd7733c39a6a@mail.gmail.com> In-Reply-To: <3bbf2fe10909290839w305c85c3t1532bd7733c39a6a@mail.gmail.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <200909291953.36373.max@love2party.net> X-Provags-ID: V01U2FsdGVkX18qVRQYFf1PVC1qzVwMsFNnHgarA7fQV7fohnS K4J6zSLPdqGPUHBmCnLk0l2YiiEk13oEUFTfBvTpy7be+g4s83 Tf3vU72Qjs= Cc: Attilio Rao , Fabio Checconi Subject: Re: sx locks and memory barriers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Sep 2009 17:53:39 -0000 On Tuesday 29 September 2009 17:39:37 Attilio Rao wrote: > 2009/9/25 Fabio Checconi : > > Hi all, > > looking at sys/sx.h I have some troubles understanding this comment: > > > > * A note about memory barriers. Exclusive locks need to use the same > > * memory barriers as mutexes: _acq when acquiring an exclusive lock > > * and _rel when releasing an exclusive lock. On the other side, > > * shared lock needs to use an _acq barrier when acquiring the lock > > * but, since they don't update any locked data, no memory barrier is > > * needed when releasing a shared lock. > > > > In particular, I'm not understanding what prevents the following sequence > > from happening: > > > > CPU A CPU B > > > > sx_slock(&data->lock); > > > > sx_sunlock(&data->lock); > > > > /* reordered after the unlock > > by the cpu */ > > if (data->buffer) > > sx_xlock(&data->lock); > > free(data->buffer); > > data->buffer = NULL; > > sx_xunlock(&data->lock); > > > > a = *data->buffer; > > > > IOW, even if readers do not modify the data protected by the lock, > > without a release barrier a memory access may leak past the unlock (as > > the cpu won't notice any dependency between the unlock and the fetch, > > feeling free to reorder them), thus potentially racing with an exclusive > > writer accessing the data. > > > > On architectures where atomic ops serialize memory accesses this would > > never happen, otherwise the sequence above seems possible; am I missing > > something? > > I think your concerns are right, possibly we need this patch: > http://www.freebsd.org/~attilio/sxrw_unlockb.diff > > However speaking with John we agreed possibly there is a more serious > breakage. Possibly, memory barriers would also require to ensure the > compiler to not reorder the operation, while right now, in FreeBSD, they > just take care of the reordering from the architecture perspective. > The only way I'm aware of GCC offers that is to clobber memory. > I will provide a patch that address this soon, hoping that GCC will be > smart enough to not overhead too much the memory clobbering but just > try to understand what's our purpose and servers it (I will try to > compare code generated before and after the patch at least for tier-1 > architectures). Does GCC really reorder accesses to volatile objects? The C Standard seems to object: 5.1.2.3 - 2 Accessing a volatile object, modifying an object, modifying a file, or calling a function that does any of those operations are all side effects,11) which are changes in the state of the execution environment. Evaluation of an expression may produce side effects. At certain specified points in the execution sequence called sequence points, all side effects of previous evaluations shall be complete and no side effects of subsequent evaluations shall have taken place. (A summary of the sequence points is given in annex C.) I might be reading this wrong, of course. -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News