Date: Mon, 11 Sep 2000 18:17:24 -0700 (PDT) From: Frank Mayhar <frank@exit.com> To: mjacob@feral.com Cc: Frank Mayhar <frank@exit.com>, Greg Lehey <grog@lemis.com>, John Baldwin <jhb@pike.osd.bsdi.com>, Mark Murray <markm@FreeBSD.ORG>, FreeBSD-arch@FreeBSD.ORGG 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 Message-ID: <200009120122.e8C1MdI57055@realtime.exit.com> In-Reply-To: <Pine.LNX.4.21.0009111801490.25916-100000@zeppo.feral.com> from Matthew Jacob at "Sep 11, 2000 06:02:26 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200009120122.e8C1MdI57055>