From owner-freebsd-arch@FreeBSD.ORG Fri May 21 06:59:08 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 31F0D16A4CE for ; Fri, 21 May 2004 06:59:08 -0700 (PDT) Received: from mail3.speakeasy.net (mail3.speakeasy.net [216.254.0.203]) by mx1.FreeBSD.org (Postfix) with ESMTP id 12C3B43D48 for ; Fri, 21 May 2004 06:59:08 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: (qmail 6235 invoked from network); 21 May 2004 13:58:56 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 21 May 2004 13:58:56 -0000 Received: from 10.50.40.205 (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id i4LDwoRK076727; Fri, 21 May 2004 09:58:51 -0400 (EDT) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-arch@FreeBSD.org Date: Fri, 21 May 2004 09:59:24 -0400 User-Agent: KMail/1.6 References: <20040520.205403.08940889.imp@bsdimp.com> In-Reply-To: <20040520.205403.08940889.imp@bsdimp.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200405210959.25368.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: arch@FreeBSD.org cc: julian@elischer.org Subject: Re: atomic reference counting primatives. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 May 2004 13:59:08 -0000 On Thursday 20 May 2004 10:54 pm, M. Warner Losh wrote: > In message: > > > Julian Elischer writes: > : This has been raised before but I've come across uses for it again and > : again so I'm raising it again. > : JHB once posted some atomic referenc counting primatives. (Do you still > : have them John?) > : Alfred once said he had soem somewhere too, and other s have commentted > : on this before, but we still don't seem to have any. > : > : every object is reference counted with its own code and > : sometimes it's done poorly. > : > : Some peiople indicated that there are cases where a generic refcounter > : can not be used and usd this as a reason to not have one at all. > : > : So, here are some possibilities.. > : my first "write it down without too much thinking" effort.. > : > : typedef {mumble} refcnt_t > : > : refcnt_add(refcnt_t *) > : Increments the reference count.. no magic except to be atomic. > : > : > : int refcnt_drop(refcnt *, struct mutex *) > : Decrements the refcount. If it goes to 0 it returns 0 and locks the > : mutex (if the mutex is supplied).. > > What prevents refcnt_add() from happening after ref count drops to 0? > Wouldn't that be a race? Eg, if we have two threads: > > > Thread A Thread B > > objp = lookup(); > [1] refcnt_drop(&objp->ref, &objp->mtx); > [2] refcnt_add(&obj->ref); > BANG! > > If [1] happens before [2], then bad things happen at BANG! If [2] > happens before [1], then the mutex won't be locked at BANG and things > is good. Thread A believes it has a valid reference to objp after the > refcnt_add and no way of knowing otherwise. > > Is there a safe way to use the API into what you are proposing? This situation can't happen if you are properly using reference counting. For the reference count to be at 1 in thread B, it has to have the only reference meaning that the object has already been removed from any lists, etc. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org