From owner-freebsd-arch@FreeBSD.ORG Thu May 20 19:54:39 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 9B13516A4CE for ; Thu, 20 May 2004 19:54:39 -0700 (PDT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 42C5343D31 for ; Thu, 20 May 2004 19:54:39 -0700 (PDT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.11/8.12.11) with ESMTP id i4L2s2GA038430; Thu, 20 May 2004 20:54:02 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Thu, 20 May 2004 20:54:03 -0600 (MDT) Message-Id: <20040520.205403.08940889.imp@bsdimp.com> To: julian@elischer.org From: "M. Warner Losh" In-Reply-To: References: X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: arch@freebsd.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 02:54:39 -0000 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? Warner