From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 10 17:40:30 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E6BD816A4B3; Fri, 10 Oct 2003 17:40:30 -0700 (PDT) Received: from kientzle.com (h-66-166-149-50.SNVACAID.covad.net [66.166.149.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 92C0A43F3F; Fri, 10 Oct 2003 17:40:28 -0700 (PDT) (envelope-from kientzle@acm.org) Received: from acm.org ([66.166.149.54]) by kientzle.com (8.12.9/8.12.9) with ESMTP id h9B0eJkX047883; Fri, 10 Oct 2003 17:40:19 -0700 (PDT) (envelope-from kientzle@acm.org) Message-ID: <3F875172.5010309@acm.org> Date: Fri, 10 Oct 2003 17:40:18 -0700 From: Tim Kientzle User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4) Gecko/20031006 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bruce M Simpson References: <20031008083059.GA520@garage.freebsd.pl> <20031008114506.I63940@beagle.fokus.fraunhofer.de> <20031008101251.GG6524@saboteur.dek.spc.org> In-Reply-To: <20031008101251.GG6524@saboteur.dek.spc.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: rwatson@freebsd.org cc: hsu@freebsd.org cc: freebsd-hackers@freebsd.org Subject: Re: Dynamic reads without locking. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: kientzle@acm.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Oct 2003 00:40:31 -0000 Bruce M Simpson wrote: > On Wed, Oct 08, 2003 at 11:51:06AM +0200, Harti Brandt wrote: >>You need to lock when reading if you insist on consistent data. Even a >>simple read may be non-atomic (this should be the case for 64bit >>operations on all our platforms). > > Or keep a generation count to detect pre-emption (the devstat code does > this, amongst other things), and try again if you lost the race. Are you sure that code is right? I'm not at all convinced that the compiler is forbidden from simply optimizing away most of your generation count code. (Just because gcc doesn't do so today doesn't mean that icc or gcc 4 won't.) I'd be a lot more convinced by code that allocated a non-shared buffer, locked the mutex, copied the data into the buffer, unlocked, pushed the data out from the buffer, then released the buffer. Many attempts to avoid locking are foiled by compiler optimizations. Tim Kientzle