From owner-freebsd-arch Mon Sep 25 10: 5:50 2000 Delivered-To: freebsd-arch@freebsd.org Received: from pike.osd.bsdi.com (pike.osd.bsdi.com [204.216.28.222]) by hub.freebsd.org (Postfix) with ESMTP id 7462237B424 for ; Mon, 25 Sep 2000 10:05:47 -0700 (PDT) Received: from foo.osd.bsdi.com (root@foo.osd.bsdi.com [204.216.28.137]) by pike.osd.bsdi.com (8.11.0/8.9.3) with ESMTP id e8PH5ki40585; Mon, 25 Sep 2000 10:05:46 -0700 (PDT) (envelope-from jhb@foo.osd.bsdi.com) Received: (from jhb@localhost) by foo.osd.bsdi.com (8.11.0/8.11.0) id e8PH3rn36503; Mon, 25 Sep 2000 10:03:53 -0700 (PDT) (envelope-from jhb) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Mon, 25 Sep 2000 10:03:53 -0700 (PDT) Organization: BSD, Inc. From: John Baldwin To: Daniel Eischen Subject: Re: Mutexes and semaphores Cc: arch@FreeBSD.ORG Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 24-Sep-00 Daniel Eischen wrote: > On Sun, 24 Sep 2000, John Polstra wrote: > 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. > Another thing, is in > our support for recursive mutexes is that they make the calling > conventions overly complex (with the silly flag argumuents to > mtx_enter()). Uhhh. With the exception of the mtx_enter() for sched_lock in mi_switch() that specifies M_RLIKELY, all of the mutex flags currently in use have _nothing_ to do with recursion. MTX_DEF/MTX_SPIN are used to distinguish spin locks from sleep locks. The use of those flags is another matter for discussion, but the flags have very, very little to do with recursion. > 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. Most of the "complexity" in the mutex code lies in putting processes to sleep and waking them back up again for sleep locks, and in the currently broken and disabled code to propagate a sleeping process' priority to the process holding the mutex it is waiting for. > My $0.02 for what it's worth... > > -- > Dan Eischen -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.Baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message