From owner-freebsd-arch Fri Mar 16 15:33:29 2001 Delivered-To: freebsd-arch@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 29C7937B719; Fri, 16 Mar 2001 15:33:26 -0800 (PST) (envelope-from mjacob@feral.com) Received: from zeppo.feral.com (IDENT:mjacob@zeppo [192.67.166.71]) by feral.com (8.9.3/8.9.3) with ESMTP id PAA24825; Fri, 16 Mar 2001 15:33:28 -0800 Date: Fri, 16 Mar 2001 15:33:24 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: Terry Lambert Cc: John Baldwin , arch@FreeBSD.ORG Subject: Re: man pages In-Reply-To: <200103162323.QAA18245@usr07.primenet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Actually, I think you only need disable_intr && restore_intr, which should be > > paired over tight MD code sections, and yes, leaving it ambigious is desirable > > IMO. > > [ .. man page ... ] > > > It is deliberately left undefined whether this disables interrupts > > only on the calling CPU or whether this disables interrupts across > > the entire system. Clearly it must be used with caution and does > > not eliminate the need for appropriate locking. > > > Rather than doing this, wouldn't it just be easier to say that it > can not be uses for inter-CPU synchronization, but may result in > inter-CPU synchronization as a side effect on some architectures? I wouldn't even go that far. The purpose of disable_intr is to do what it says- disable interrupts. One purpose might be something like disabling interrupts prior to (re)entering the PROM for reboot or debugging purposes (a la SPARC/OBB). It's left vague as to whether this has a global or per-cpu because each platform has to provide it, but the specifics of the scope of how it works is platform specific. In AT&T parlance, it's a DDI function, not a DKI function. Let's assume we have a broadcast interrupt platform, but disable_intr only disables interrupt recognition for the calling CPU. One might say it's a useless function- I'd say not. You *still* use locks to keep threads on other cpus out of critical regions- but you may have wanted to make sure you wouldn't be getting any ithreads pending on the *calling* cpu- I'm sure jhb can think of a number of cases this would help. > Given that it's going to be used, and it's vaue, you might even > go so far as to claim "as an undesirable side effect"... In order to address some other folks' expressed concerns that this might be 'useless', some very careful wording has to occur. I don't think we want to say anything at all about using this as a synchronization mechanism, unless to say "Do *not* consider this to be a method for synchronization" -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message