Date: Sat, 11 Oct 2003 14:19:31 -0700 From: Tim Kientzle <kientzle@acm.org> To: Bruce M Simpson <bms@spc.org> Cc: rwatson@freebsd.org Subject: Re: Dynamic reads without locking. Message-ID: <3F8873E3.1070403@acm.org> In-Reply-To: <20031011081822.GA679@saboteur.dek.spc.org> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3F8873E3.1070403>