From owner-freebsd-hackers@FreeBSD.ORG Tue Sep 29 16:09:04 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 B0A641065693; Tue, 29 Sep 2009 16:09:04 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-bw0-f227.google.com (mail-bw0-f227.google.com [209.85.218.227]) by mx1.freebsd.org (Postfix) with ESMTP id 0E4EB8FC1D; Tue, 29 Sep 2009 16:09:03 +0000 (UTC) Received: by bwz27 with SMTP id 27so3995680bwz.43 for ; Tue, 29 Sep 2009 09:09:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=wzrcKIMdiTDx5Kc9S75bUIsMwF9fQRfv1VHz2btbiTA=; b=lBvxBU2aQc1sPQHRdeaFb+/Kh3ohGWwpg9onHvOH22HFiBPHpr5EpANnoIOS49dNH7 XUGcduQ7kW6EHveqztwT1Mn49rxegQVgqprFSnsztGVz0fTNx157pDDLoARCu43Uvwq6 q8qR/TdRf4dQCmBBczp4F8lSEJGUuksLF2SYQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=KuVlIXsjbRgpyXi7/vk19C3D+5BCXPvDZaftLVz94rCC4R4KaUm7JWNjHgnZcQ+R9n MN0zKmhZGg9zIe8MTUdDzI07BNS+rOxQk3D9Gre1iuSSypak9xIrPELAUOQZWomgLJqe bXESVIfdwnwVcyz5vdHK848S+VzBVxk4todLs= MIME-Version: 1.0 Sender: asmrookie@gmail.com Received: by 10.223.144.70 with SMTP id y6mr1330962fau.12.1254238777691; Tue, 29 Sep 2009 08:39:37 -0700 (PDT) In-Reply-To: <20090924224935.GW473@gandalf.sssup.it> References: <20090924224935.GW473@gandalf.sssup.it> Date: Tue, 29 Sep 2009 17:39:37 +0200 X-Google-Sender-Auth: 07c424f4586d0684 Message-ID: <3bbf2fe10909290839w305c85c3t1532bd7733c39a6a@mail.gmail.com> From: Attilio Rao To: Fabio Checconi Content-Type: text/plain; charset=UTF-8 Cc: 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: Tue, 29 Sep 2009 16:09:04 -0000 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). Attilio -- Peace can only be achieved by understanding - A. Einstein