From owner-freebsd-smp Tue Oct 31 11:55:17 2000 Delivered-To: freebsd-smp@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 2E9E337B479; Tue, 31 Oct 2000 11:55:14 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id e9VJt8C04227; Tue, 31 Oct 2000 11:55:08 -0800 (PST) Date: Tue, 31 Oct 2000 11:55:07 -0800 From: Alfred Perlstein To: Chuck Paterson Cc: Cedric Berger , Robert Watson , freebsd-smp@FreeBSD.ORG Subject: Re: Reference count invariants in a fine-grained threaded environment Message-ID: <20001031115506.Y22110@fw.wintelcom.net> References: <20001031102110.V22110@fw.wintelcom.net> <200010311857.LAA02433@berserker.bsdi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: <200010311857.LAA02433@berserker.bsdi.com>; from cp@bsdi.com on Tue, Oct 31, 2000 at 11:57:09AM -0700 Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org * Chuck Paterson [001031 10:57] wrote: > Alfred, > > I'm a little surprised. I thought you won the argument to > use atomic operations as long as long as all the needed operations > such as the decrement and test, and examine without modification > were present. You certainly convinced me. I though we had got to > the point of just working out what we wanted to do for size. > > This is of course only where a mutex isn't already required > for internal data integrity. Robert Watson's explanation on how he was going to handle atomic ops with mutexes rather than discussing my proposed atomic_t (or atomicref_t) made it pretty clear that either he has somehow missed (happens to disagree with) my proposals. I've also been unable to convice the SMP project leader Jason Evans and the main smp coder Jonathan Baldwin of the merits of atomic_t. My proposal is a simple atomic type that has these features: 1) needs to be 'constructed' and 'destroyed' via functions 2) offers at least/about 24 bits of precision 3) (optional) supports AND/OR ops 4) supports increments and decrements with a special "decrement and return if 0 has been reached" The virtues of atomic_t are: 1) cheaper (if not abused, meaing one probably shouldn't implement something like the tcpstats struct using atomics because you may need to perform several atomic ops in a row and it would be cheaper to hold a mutex over the entire struct) 2) less storage requirement on most archs (enjoy the bloat on ucred :( if you use mutexes all over) 3) if an arch doesn't support atomic memory ops the con/destructors can be used to initialize a mutex within the machine depandant struct. 4) non blocking on most archs that support it without mutexes Linux supports these ops through includes/arch/asm-{arch}/atomic.h headers if anyone cares to check out what's faster and possible and cleaner. I'm tired of trying to reach concensus on the issue. Robert, if you like this let me know and I'll hand you what I have so far which are the patches for i386. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message