From owner-freebsd-arch Mon Sep 25 12:38:44 2000 Delivered-To: freebsd-arch@freebsd.org Received: from smtp05.primenet.com (smtp05.primenet.com [206.165.6.135]) by hub.freebsd.org (Postfix) with ESMTP id BF13E37B424; Mon, 25 Sep 2000 12:38:33 -0700 (PDT) Received: (from daemon@localhost) by smtp05.primenet.com (8.9.3/8.9.3) id MAA08146; Mon, 25 Sep 2000 12:38:48 -0700 (MST) Received: from usr02.primenet.com(206.165.6.202) via SMTP by smtp05.primenet.com, id smtpdAAAbdaa0p; Mon Sep 25 12:38:42 2000 Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id MAA29311; Mon, 25 Sep 2000 12:38:23 -0700 (MST) From: Terry Lambert Message-Id: <200009251938.MAA29311@usr02.primenet.com> Subject: Re: Mutexes and semaphores To: jhb@FreeBSD.ORG (John Baldwin) Date: Mon, 25 Sep 2000 19:38:22 +0000 (GMT) Cc: eischen@vigrid.com (Daniel Eischen), arch@FreeBSD.ORG In-Reply-To: from "John Baldwin" at Sep 25, 2000 10:03:53 AM X-Mailer: ELM [version 2.5 PL2] 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 > > But you can't then use a recursive mutex in conjunction with msleep > > (cv_wait) which forces you to use yet another mutex. This is fine, > > but it adds confusion for the programmer. > > This is a problem. However, for one thing we currently have a > KASSERT() that panic's if you msleep() on a recursed mutex. However, > one could also change msleep() to function like mi_switch() does > with Giant and have it fully release the lock before sleeping, but > this probably would not be a Good Thing. No. It would not be a good thing. Consider that I may be sleeping on the acquisition of the third out of three mutexes. > > If we are going to support recursive mutex, I think it would be > > better to add separate calls/macros/data types to support them, > > so the the mtx mutexes can be simplified. Calls to mtx_enter > > with the recursive mutex type wouldn't even compile. > > Err, the recursive nature of the mutexes is very trivial. It > doesn't affect the complexity of the mutexes at all. Yes, it does. Ownership precludes hand-off. Recusrion support implies permission and tacit approval. A mutex is not recursive. There are things you simply can not implement when recursion is permitted for all of your primitives. The most obvious argument is still that a mutex is intended to protect data, not code. Recursion is only required if the mutex is actually protecting reentrancy of code, not access to data. How would you implement vop_lookup() using a recusring mutex; considering the ownership handoff which must occur? You will need a non-recursing mutex to protect yout recursing mutex during the process of changing the owner (consider an ihash reclaim during lookup, or ownership of a vnode mutex on a vnode retrieved from the DNLC). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message