From owner-freebsd-hackers@FreeBSD.ORG Sat Oct 11 14:19:35 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 0293616A4B3; Sat, 11 Oct 2003 14:19:35 -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 445A743FB1; Sat, 11 Oct 2003 14:19:33 -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 h9BLJWkX053390; Sat, 11 Oct 2003 14:19:32 -0700 (PDT) (envelope-from kientzle@acm.org) Message-ID: <3F8873E3.1070403@acm.org> Date: Sat, 11 Oct 2003 14:19:31 -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> <3F875172.5010309@acm.org> <3F8795A9.5020409@acm.org> <20031011081822.GA679@saboteur.dek.spc.org> In-Reply-To: <20031011081822.GA679@saboteur.dek.spc.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-hackers@freebsd.org cc: hsu@freebsd.org cc: rwatson@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 21:19:35 -0000 Bruce M Simpson wrote: > On Fri, Oct 10, 2003 at 10:31:21PM -0700, Tim Kientzle wrote: > >>On further inspection, I'm pretty sure that sys/kern/subr_devstat.c >>is not correct. > > OK. What about the shared page interface? Specifically the comment > above devstat_end_transaction(). I'm not entirely happy about it, but maybe I just need to study it more. The atomic* operations here are implementing a partial lock. What's not entirely clear to me is whether it's sufficient or not. The fact that the transaction interface is using a different locking mechanism than the rest of the code is suspicious. > The generation count is used by > the old sysctl interface. The shared page interface has a liberal > sprinkling of atomic*() instructions. Back when I was following the Java threading mailing list, I saw a lot of "what about this" examples that I studied and lots of other people studied, and it often took a long time for someone to figure out why it was wrong. And, for as long as I was following the list, it was _always_ wrong. Every single trick for eliminating locks that someone came up with didn't work. Usually, the problem was some compiler optimization, processor optimization, or cache behavior that would break the code. Using generation counts in sysctl code makes perfect sense as a tool for notifying user space whether something has changed since they last checked. Using it as a tool to eliminate locking is another thing entirely. Tim