From owner-freebsd-smp Thu Dec 21 10:41: 3 2000 From owner-freebsd-smp@FreeBSD.ORG Thu Dec 21 10:41:01 2000 Return-Path: Delivered-To: freebsd-smp@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id C34C937B402; Thu, 21 Dec 2000 10:41:01 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id eBLIf0c09482; Thu, 21 Dec 2000 10:41:00 -0800 (PST) Date: Thu, 21 Dec 2000 10:41:00 -0800 From: Alfred Perlstein To: Julian Elischer Cc: smp@FreeBSD.ORG, archie@FreeBSD.ORG Subject: Re: looking for locking advice.. Message-ID: <20001221104100.T19572@fw.wintelcom.net> References: <3A424D2F.6524EC06@elischer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3A424D2F.6524EC06@elischer.org>; from julian@elischer.org on Thu, Dec 21, 2000 at 10:34:23AM -0800 Sender: bright@fw.wintelcom.net Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org * Julian Elischer [001221 10:35] wrote: > > My questions are: > > Do we yet support full sleeping by interrupt threads? And if so, what is the > general > thought on this? How do we ensure that the interrupt thread is sheduled REALLY > SOON > after the lock is released. Is it preferable to sleep an interrupt thread > instead of blocking the interrupts and stopping it from happenning in the first > place? Is there a good way to tell that the caller is in an interrupt context? You really don't want to bother with this anymore, yes interrupts can block on a mutex, and only SPIN mutexes block interrupts _only_ on the processor that has a spinlock held. I wouldn't worry all too much about the distiction between interrupt execution state versus non-interrupt. Sure device nodes want to complete as soon as possible, however eventually we'll have _multiple_ software interrupt threads running on each processor so latency is reduced. As far as your netgraph hashlookup, I would use macros along the line of Jake's proctree lock, for now define them to be simple mutexes, if at a later time we have rwlocks you can easily convert it over. This is what I'm planning on doing for the af_unix listlocks. -- -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-smp" in the body of the message