Date: Fri, 13 Oct 2000 02:34:39 -0700 From: Peter Wemm <peter@netplex.com.au> To: Terry Lambert <tlambert@primenet.com> Cc: bright@wintelcom.net (Alfred Perlstein), arch@FreeBSD.ORG Subject: Re: we need atomic_t Message-ID: <200010130934.e9D9YdG38096@netplex.com.au> In-Reply-To: <200010130926.CAA23043@usr09.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Terry Lambert wrote:
> > What's annoying me here is that everyone wants atomic_t to
> > do all these amazing things for which i'm not presenting it
> > for. All I want it for is:
> >
> > 1) refcounting in ucred
> > 2) refcounting in mbuf
> > 3) refcounting in uidinfo
> > 4) providing at least 16 bits of atomically-or/and-able bits for
> > certain flags structures that I may want to have atomic ops for.
> >
> > If anyone has a situation that atomic_t as presented here is
> > unsuitable for then they are welcome to get off my back and
> > make up some other magic type to address their problem.
>
> Why call it "atomic_t" instead of "long", then?
Because certain arch'es that have a greater than zero probability of having
a FreeBSD port cannot do atomic operations on entities larger than 24 bits.
Therefore, atomic_add_long() etc cannot exist on that system, but atomic_t
can.
typedef struct {
char atomic_lock; /* and padding */
u_int32_t value;
} atomic_t;
Linux has to do this to run on sparc, for example.
Cheers,
-Peter
--
Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au
"All of this is for nothing if we don't go to the stars" - JMS/B5
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?200010130934.e9D9YdG38096>