From owner-freebsd-arch Fri Oct 13 2:34:45 2000 Delivered-To: freebsd-arch@freebsd.org Received: from netplex.com.au (adsl-64-163-195-99.dsl.snfc21.pacbell.net [64.163.195.99]) by hub.freebsd.org (Postfix) with ESMTP id 5E0FF37B502 for ; Fri, 13 Oct 2000 02:34:43 -0700 (PDT) Received: from netplex.com.au (peter@localhost [127.0.0.1]) by netplex.com.au (8.11.0/8.9.3) with ESMTP id e9D9YdG38096; Fri, 13 Oct 2000 02:34:39 -0700 (PDT) (envelope-from peter@netplex.com.au) Message-Id: <200010130934.e9D9YdG38096@netplex.com.au> X-Mailer: exmh version 2.1.1 10/15/1999 To: Terry Lambert Cc: bright@wintelcom.net (Alfred Perlstein), arch@FreeBSD.ORG Subject: Re: we need atomic_t In-Reply-To: <200010130926.CAA23043@usr09.primenet.com> Date: Fri, 13 Oct 2000 02:34:39 -0700 From: Peter Wemm Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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