From owner-freebsd-arch Thu Sep 28 11:15: 9 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mass.osd.bsdi.com (adsl-63-202-176-106.dsl.snfc21.pacbell.net [63.202.176.106]) by hub.freebsd.org (Postfix) with ESMTP id 232D037B423 for ; Thu, 28 Sep 2000 11:14:57 -0700 (PDT) Received: from mass.osd.bsdi.com (localhost [127.0.0.1]) by mass.osd.bsdi.com (8.11.0/8.9.3) with ESMTP id e8SIGLA01632; Thu, 28 Sep 2000 11:16:21 -0700 (PDT) (envelope-from msmith@mass.osd.bsdi.com) Message-Id: <200009281816.e8SIGLA01632@mass.osd.bsdi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Alfred Perlstein Cc: arch@freebsd.org Subject: Re: we need atomic_t In-reply-to: Your message of "Thu, 28 Sep 2000 11:06:37 PDT." <20000928110637.U7553@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 28 Sep 2000 11:16:21 -0700 From: Mike Smith Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Linux has a datatype called "atomic_t", very useful for refcounts > and struct counters like tcpstat. My impression is that it's the > largest type an arch can support atomic ops on without weird > gyrations and/or extremely expensive operations. sig_atomic_t. > This would replace our atomic_op_type with just atomic_op and make > code easier to read and get right. I strongly disagree. The atomic__ interface is useful and necessary and should remain. I don't agree that this would make anything easier. In particular, the explicit use of the atomic_* operations makes the atomicity constraints very clear. > I'm already seeing a pretty good examples of where this can be > applied: > > 1) struct ucred->cr_ref > 2) struct uidinfo->ui_ref > 3) tcpstats > 4) other stats :) > 5) mbuf external ref counts > > I don't have the gcc-assembler-foo to do this optimally without > directly copying from Linux which isn't acceptable. In most cases, you're manipulating the reference count under a mutex (since there's no other way to avoid the race where someone else frees your structure while you're in the process of dereferencing it), so this is largely unnecessary. > Can anyone snap this up? I'd really appreciate it. Hold it right there, sunshine. 8) -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message