From owner-freebsd-arch Thu Oct 12 23: 8:10 2000 Delivered-To: freebsd-arch@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 9B80837B503 for ; Thu, 12 Oct 2000 23:08:08 -0700 (PDT) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id e9D687t02432; Thu, 12 Oct 2000 23:08:07 -0700 (PDT) Date: Thu, 12 Oct 2000 23:08:07 -0700 From: Alfred Perlstein To: Terry Lambert Cc: arch@FreeBSD.ORG Subject: Re: we need atomic_t Message-ID: <20001012230807.H272@fw.wintelcom.net> References: <20001012192229.F272@fw.wintelcom.net> <200010130251.TAA03945@usr05.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: <200010130251.TAA03945@usr05.primenet.com>; from tlambert@primenet.com on Fri, Oct 13, 2000 at 02:51:31AM +0000 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Terry Lambert [001012 19:51] wrote: > > The reason for atomic_init/destroy is to intialize mutexes if they > > are needed on the arch. Basically atomic64_t on 32bit arches would > > be a struct with a 64bit value and a mutex to protect it. > > Tee hee hee. > > How do I initialize the mutex that protects the mutex? > > I think it's time to learn from the POSIX threads mutex > implementation, wherein it is impossible to statically > initialize a mutex, and to obtain that appearance, you > have to trick the loader into doing the work using the > section which is used for the construction of virtual > base classes in C++ (see my modifications to the STL, as > applied to the Moscow Center for Supercomuting Activites > STL, which is the most up to date STL available). 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. thanks, -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message