From owner-freebsd-smp Tue Oct 31 14: 8:44 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 81B8E37B479; Tue, 31 Oct 2000 14:08:39 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id e9VM8dR08665; Tue, 31 Oct 2000 14:08:39 -0800 (PST) Date: Tue, 31 Oct 2000 14:08:39 -0800 From: Alfred Perlstein To: Robert Watson Cc: freebsd-smp@FreeBSD.org Subject: Re: Reference count invariants in a fine-grained threaded environment Message-ID: <20001031140838.A22110@fw.wintelcom.net> References: <20001031115506.Y22110@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: ; from rwatson@FreeBSD.org on Tue, Oct 31, 2000 at 03:14:08PM -0500 Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org * Robert Watson [001031 12:14] wrote: > > I refuse to comment on the various means by which atomic operations might > be implemented, as I am utterly unqualified to comment on that topic. :-) > I would be happy with atomic operations in the general case as long as > either (a) we provide an alternative that's easy to use for platforms that > don't have atomic increment and decrement, or (b) we don't care about > platforms without them. This is a moot point if there are no platforms > not supporting the atomic operation requirements, but I am not qualified > to make statements about that either. :-) My proposal offers a transparent implementation of 'a' via macro/inlines. On machines that don't support atomic ops we can stick a mutex into the struct hidden by atomic_t. However it's impossible to stick a mutex into a 'uint'. -- -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