From owner-freebsd-arch Mon Nov 12 15:32:31 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail11.speakeasy.net (mail11.speakeasy.net [216.254.0.211]) by hub.freebsd.org (Postfix) with ESMTP id BD31737B417 for ; Mon, 12 Nov 2001 15:32:28 -0800 (PST) Received: (qmail 53828 invoked from network); 12 Nov 2001 23:32:27 -0000 Received: from unknown (HELO laptop.baldwin.cx) ([64.81.54.73]) (envelope-sender ) by mail11.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 12 Nov 2001 23:32:27 -0000 Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <200111122320.fACNKLC07027@apollo.backplane.com> Date: Mon, 12 Nov 2001 15:32:21 -0800 (PST) From: John Baldwin To: Matthew Dillon Subject: Re: cur{thread/proc}, or not. Cc: Terry Lambert , Cc: Terry Lambert , Robert Watson , freebsd-arch@FreeBSD.ORG Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 12-Nov-01 Matthew Dillon wrote: >: >:Yep. They use a mutex for the refcount for now, but I still have patches >:that >:some people don't like for implementing a simple refcount API just using >:atomic >:operations. >: >:-- >: >:John Baldwin -- http://www.FreeBSD.org/~jhb/ > > I haven't seen your patches but I like the idea of a simple API for > incrementing and decrementing a refcnt_t type of variable that > hides the underlying 'how'. For example, on some architectures > you could use atomic ops, on others you could use a small pool > of mutexes. http://www.freebsd.org/~jhb/patches/refcount.patch It's slightly different than this in that refcount_drop() returns a boolean that is true if the count just dropped to zero. It only uses mutexes when using debugging and doesn't use a pool, but currently it is implemented completely with atomic ops on all currently supported archs. Hmm, it needs a change in that no memory barriers are really needed except that maybe the atomic_add should use a release barrier. This refcount has some problems, however. The only reliable way to do a refcount_shared() primitive would be to do int refcount_shared(refcount_t *count) { int rval; rval = !refcount_drop(count); refcount_hold(count); } But that is evil and has a race condition. Changing refcount_drop() to return the current value would be more workable I suppose and would allow you to do this by doing a hold and then a drop and see if the value is > 1 to see if it's shared. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message