Date: Fri, 16 Mar 2001 15:33:24 -0800 (PST) From: Matthew Jacob <mjacob@feral.com> To: Terry Lambert <tlambert@primenet.com> Cc: John Baldwin <jhb@FreeBSD.ORG>, arch@FreeBSD.ORG Subject: Re: man pages Message-ID: <Pine.LNX.4.21.0103161525550.773-100000@zeppo.feral.com> In-Reply-To: <200103162323.QAA18245@usr07.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.4.21.0103161525550.773-100000>