From owner-freebsd-arch Mon Sep 25 14:39:24 2000 Delivered-To: freebsd-arch@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 7AD7537B424 for ; Mon, 25 Sep 2000 14:39:08 -0700 (PDT) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id e8PLcsH08288; Mon, 25 Sep 2000 14:38:54 -0700 (PDT) Date: Mon, 25 Sep 2000 14:38:54 -0700 From: Alfred Perlstein To: Matt Dillon Cc: Daniel Eischen , John Polstra , arch@FreeBSD.ORG Subject: Re: Mutexes and semaphores Message-ID: <20000925143853.J9141@fw.wintelcom.net> References: <200009252123.e8PLN5F84806@earth.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: <200009252123.e8PLN5F84806@earth.backplane.com>; from dillon@earth.backplane.com on Mon, Sep 25, 2000 at 02:23:05PM -0700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Matt Dillon [000925 14:23] wrote: > : > :Mutexes should protect data. If you want to allow recursive ownership of > :data, then keep your own owner and ref count field in the protected data > :and use the mutex properly (release it after setting the owner or > :incrementing the ref count). You don't need to hold the mutex, and > :now you can use the same mutex for msleep/cv_wait. > : > :-- > :Dan Eischen > > Mutexes protect data *CONSISTENCY*, not data. There is a big difference. > Probably 95% of the kernel assumes data consistency throughout any given > routine. If that routine must call other routines (and most do), then > you have a major issue to contend with in regards to how to maintain > consistency across the call. > > There are several ways to deal with it: > > * The subroutine calls are not allowed to block - lots of examples of > this in the VM and other subsystems. > > * You use a heavy-weight lock instead of a mutex - an example > of this would be the VFS subsystem (vnode locks). > > * You engineer the code to allow data to change out from under > it at certain points (such as when something blocks) - probably > the best example is vm_fault in the VM subsystem. > > Unfortunately, all but the first can lead to serious bugs. Consider > how many bugs have been fixed in the VFS and VM subsystems just in the > last year that have been related to data consistency issues and you'll > understand. > > The first issue - not allowing a subroutine call to block, when such a > case exists, is the perfect place to put a recursive mutex. If you don't > use a recursive mutex at that point then you wind up having to > reengineer and rewrite big pieces of the code, or you wind up writing > lots of little tag routines to do end-runs around the mutexes or to > pass a flag that indicates that the mutex is already held and should > not be obtained again, and so forth. > > Remember, I'm not talking about subsystem A calling subsystem B here, > I'm talking about subsystem A calling itself. That is, a situation > where you are not obtaining several different mutexes but are instead > obtaining the same mutex several times. > > Frankly, fewer bugs will be introduced into the code by avoiding the > reengineering and using recursive mutexes at appropriate points. What's pissing me off here (not to pick on you Matt) is that there's honestly a lot of code to be worked on where the locking issues are pretty simple (expecially when you look at how BSD/os implemented it). We should be coding and discussing existing problems with making the kernel MPsafe instead of what me *might* come across along the road. Whatever we bump into we can always beat to a pulp using lockmgr. :) And honestly, I don't like the idea of recursive mutexes, I'd rather have a super function that locks a pgrp like pg_signal_locked/_unlocked which expects the locks to be held rather than a recursive lock. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message