From owner-freebsd-smp Thu Dec 21 13:58:54 2000 From owner-freebsd-smp@FreeBSD.ORG Thu Dec 21 13:58:51 2000 Return-Path: Delivered-To: freebsd-smp@freebsd.org Received: from mail.rdc1.va.home.com (ha1.rdc1.va.home.com [24.2.32.66]) by hub.freebsd.org (Postfix) with ESMTP id 23D7D37B404; Thu, 21 Dec 2000 13:58:51 -0800 (PST) Received: from laptop.baldwin.cx ([24.6.244.187]) by mail.rdc1.va.home.com (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <20001221215850.BONL20559.mail.rdc1.va.home.com@laptop.baldwin.cx>; Thu, 21 Dec 2000 13:58:50 -0800 Content-Length: 1773 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: <3A4271B9.223CD683@elischer.org> Date: Thu, 21 Dec 2000 13:58:55 -0800 (PST) From: John Baldwin To: Julian Elischer Subject: Re: looking for locking advice.. Cc: smp@FreeBSD.ORG, archie@FreeBSD.ORG Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 21-Dec-00 Julian Elischer wrote: > John Baldwin wrote: >> >> Julian, >> >> Just use reader/writer locks for now. They can use a lockmgr backend until >> a >> more efficient reader/writer lock is implemented. As a side note, we should >> probably work up a rw lock API and define some macros that just map to >> lockmgr >> operations for now but can be optimized later. As for mutexes: you should >> be >> using sleep mutexes, not spin mutexes, in which case interrupts aren't >> disabled >> while the lock is held. Very, very, very, very few things should be using >> spin >> mutexes. Note that when a mutex is released, if any threads are blocked on >> it, >> then the thread with the highest priority is woken up so it can run. Also >> note >> that interrupt threads have a higher priority than all other threads, so >> yes, >> you can block in an interrupt thread. However, blocking an interrupt thread >> is something that should still be somewhat minimized due to shared >> interrupts >> since you will be blocking all interrupt handlers associated with a >> particular >> interrupt source, thus don't go using tsleep() in an interrupt handler, for >> example. :) > > well if I block, and I can't use sleep, what CAN I use? > I need the previously running process/thread to continue > running because it is holding the lock I want to obtain.. > when it finishes and releases the lock I want to be called to > continue.. You can block using a mutex, just don't use the tsleep(9) function as "too" much sleeping in an interrupt handler is bad. If that makes any sense. -- 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-smp" in the body of the message