From owner-freebsd-arch Mon Sep 11 18:22:24 2000 Delivered-To: freebsd-arch@freebsd.org Received: from tinker.exit.com (exit-gw.power.net [207.151.46.196]) by hub.freebsd.org (Postfix) with ESMTP id 562D637B424 for ; Mon, 11 Sep 2000 18:22:22 -0700 (PDT) Received: from realtime.exit.com (realtime [206.223.0.5]) by tinker.exit.com (8.11.0/8.11.0) with ESMTP id e8C1MLa22490 for ; Mon, 11 Sep 2000 18:22:21 -0700 (PDT) (envelope-from frank@exit.com) Received: (from frank@localhost) by realtime.exit.com (8.11.0/8.11.0) id e8C1MdI57055 for FreeBSD-arch@FreeBSD.ORG; Mon, 11 Sep 2000 18:22:39 -0700 (PDT) (envelope-from frank) From: Frank Mayhar Message-Id: <200009120122.e8C1MdI57055@realtime.exit.com> Subject: Re: cvs commit: src/sys/conf files src/sys/sys random.h src/sys/dev/randomdev hash.c hash.h harvest.c randomdev.c yarrow.c yarro In-Reply-To: from Matthew Jacob at "Sep 11, 2000 06:02:26 pm" To: mjacob@feral.com Date: Mon, 11 Sep 2000 18:17:24 -0700 (PDT) Cc: Frank Mayhar , Greg Lehey , John Baldwin , Mark Murray , FreeBSD-arch@FreeBSD.ORGG Reply-To: frank@exit.com Organization: Exit Consulting X-Copyright0: Copyright 2000 Frank Mayhar. All Rights Reserved. X-Copyright1: Permission granted for electronic reproduction as Usenet News or email only. X-Mailer: ELM [version 2.4ME+ PL68 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matthew Jacob wrote: > Frank Mayahr wrote: > > Greg Lehey wrote: > > > I've been wondering whether we shouldn't associate mutexes with data > > > structures rather than code. It's possible that it would make it > > > easier to avoid deadlocks. Thoughts? > > Speaking as a BSD/OS (and former Unixware) developer: YES! > Hmm. I would rather have assumed that this is what mutexes are about. > Semaphores gate entry in code. Mutexes provide locking on data. Simple enough. This is my take on it exactly and is how I've always approached adding locking. It's a lot simpler to do per-data structure locking than code- path locking, IMHO, as you can see all the places the data structure is used (whereas tracking down all the code paths can be a real nightmare) and one can avoid using locks where they're not needed. The latter is at least as important as putting locking in in the first place, since unnecessary locking can eat your performance alive. -- Frank Mayhar frank@exit.com http://www.exit.com/ Exit Consulting http://store.exit.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message