From owner-freebsd-hackers@FreeBSD.ORG Fri Sep 25 11:47:46 2009 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3A0671065670; Fri, 25 Sep 2009 11:47:46 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id E0C6C8FC16; Fri, 25 Sep 2009 11:47:45 +0000 (UTC) Received: from [192.168.1.4] (adsl-241-169-177.bna.bellsouth.net [74.241.169.177]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id n8PBQhuF025408 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 25 Sep 2009 07:26:45 -0400 (EDT) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: Fabio Checconi In-Reply-To: <20090924224935.GW473@gandalf.sssup.it> References: <20090924224935.GW473@gandalf.sssup.it> Content-Type: text/plain Organization: FreeBSD Date: Fri, 25 Sep 2009 06:26:37 -0500 Message-Id: <1253877997.2031.2627.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_PBL, RDNS_DYNAMIC,SPF_SOFTFAIL autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: attilio@freebsd.org, hackers@freebsd.org 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: Fri, 25 Sep 2009 11:47:46 -0000 On Fri, 2009-09-25 at 00:49 +0200, Fabio Checconi wrote: > 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. Maybe I am missing something suttle, but shouldn't the shared lock be held for all data access if you want to guarantee sanity? Meaning, if you are accessing data->* without any locks held, all bets are off. robert. > On architectures where atomic ops serialize memory accesses this would > never happen, otherwise the sequence above seems possible; am I missing > something? > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" -- Robert Noland FreeBSD