From owner-cvs-all Fri Oct 6 2:36:21 2000 Delivered-To: cvs-all@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 9E23D37B503; Fri, 6 Oct 2000 02:36:11 -0700 (PDT) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.8.7/8.8.7) with ESMTP id UAA14904; Fri, 6 Oct 2000 20:36:08 +1100 Date: Fri, 6 Oct 2000 20:36:03 +1100 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Mike Smith Cc: cvs-all@FreeBSD.org, cvs-committers@FreeBSD.org Subject: Re: cvs commit: src/sys/alpha/include atomic.h src/sys/i386/incl In-Reply-To: <200010060352.e963qPh04244@mass.osd.bsdi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 5 Oct 2000, Mike Smith wrote: > > > >> Add atomic_readandclear_int and atomic_readandclear_long. > > ... > > It should be named loadandclear(). "load" is more precise than "read". > > It should be called "atomic_exchange()", and this specific case should be > > int value = 0; > atomic_exchange(value, othervalue); > > since it's otherwise entirely redundant. Perhaps it should just be moved back to a machine-dependent place. The machine might not have either an atomic exchange or an atomic exchange with 0. I think it atomic_readandclear_int() is still only used in setdelayed(), which was MD, and setdelayed is only used in MD clock interrupt handler code. > > The instruction to do the load is even named "ld" on alphas. I will > > remove the suffixes on the atomic functions soon. It should go without > > saying that operations like load and clear, test and set, and compare and > > swap, etc., are atomic. > > It doesn't go without saying, and I think it's important from the > perspective of general code readability that we make it extremely clear > that these methods are explicitly atomic. Verbose names make code unreadable. > I'm also strongly in favour of the atomic_t proposal that Alfred put > forwards, since in many cases the atomic_*_int calls are used by default > where atomic_*_optimal_type would be better. I thought you didn't like it. It doesn't go far enough. Atomic operations shouldn't be restricted to a single type. In vm, most atomic operations are on chars and shorts because the the optimization is for space. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message