From owner-freebsd-arch Fri Mar 16 15:52:23 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (Postfix) with ESMTP id EC25637B718; Fri, 16 Mar 2001 15:52:19 -0800 (PST) (envelope-from tlambert@usr07.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.9.3/8.9.3) id QAA17397; Fri, 16 Mar 2001 16:46:16 -0700 (MST) Received: from usr07.primenet.com(206.165.6.207) via SMTP by smtp04.primenet.com, id smtpdAAAv7aySH; Fri Mar 16 16:45:57 2001 Received: (from tlambert@localhost) by usr07.primenet.com (8.8.5/8.8.5) id QAA19187; Fri, 16 Mar 2001 16:51:56 -0700 (MST) From: Terry Lambert Message-Id: <200103162351.QAA19187@usr07.primenet.com> Subject: Re: man pages To: mjacob@feral.com Date: Fri, 16 Mar 2001 23:51:56 +0000 (GMT) Cc: tlambert@primenet.com (Terry Lambert), jhb@FreeBSD.ORG (John Baldwin), arch@FreeBSD.ORG In-Reply-To: from "Matthew Jacob" at Mar 16, 2001 03:33:24 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > 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. [ ... ] > 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. Sounds like you want something like these: intr_disable_this_cpu() ithread_diable_this_cpu() ... It seems to me that the function ou are documenting is machine specific, and should be named for the architecture/CPU/etc. to which it applies. > > 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" I'd even say: Do *not* consider this to be a method for synchronization Do *not* invert inter-cpu lock ordering after calling this function, as it may result in a starvation deadlock Personally, I thinkit's useless to name a function after something which it does, rather than naming it after something which you want it to do. The distinction is subtle, I grant you, but people will be wanting to use it for what it does _in order to get a resulting desirable effect_. If it isn't cross-platform, it isn't cross platform. I don't think it's reasonable to require an English degree or a Juris Doctorate or both to be able to tell why you would want to call a function with a name that seems to imply an incorrect usage might be reasonable and safely used cross-platform. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message