Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 6 Oct 2000 20:36:03 +1100 (EST)
From:      Bruce Evans <bde@zeta.org.au>
To:        Mike Smith <msmith@FreeBSD.org>
Cc:        cvs-all@FreeBSD.org, cvs-committers@FreeBSD.org
Subject:   Re: cvs commit: src/sys/alpha/include atomic.h src/sys/i386/incl 
Message-ID:  <Pine.BSF.4.21.0010062021030.2593-100000@besplex.bde.org>
In-Reply-To: <200010060352.e963qPh04244@mass.osd.bsdi.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0010062021030.2593-100000>