From owner-freebsd-arch@FreeBSD.ORG  Wed Jun  9 19:00:43 2004
Return-Path: <owner-freebsd-arch@FreeBSD.ORG>
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 6ED1216A4CE; Wed,  9 Jun 2004 19:00:43 +0000 (GMT)
Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35])
	by mx1.FreeBSD.org (Postfix) with ESMTP
	id 5C2E943D49; Wed,  9 Jun 2004 19:00:43 +0000 (GMT)
	(envelope-from julian@elischer.org)
Received: from interjet.elischer.org ([24.7.73.28])
          by comcast.net (rwcrmhc11) with ESMTP
          id <200406091900350130096uoje>; Wed, 9 Jun 2004 19:00:35 +0000
Received: from localhost (localhost.elischer.org [127.0.0.1])
	by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id MAA59653;
	Wed, 9 Jun 2004 12:00:32 -0700 (PDT)
Date: Wed, 9 Jun 2004 12:00:30 -0700 (PDT)
From: Julian Elischer <julian@elischer.org>
To: Pawel Jakub Dawidek <pjd@FreeBSD.org>
In-Reply-To: <20040609183703.GX12007@darkness.comp.waw.pl>
Message-ID: <Pine.BSF.4.21.0406091155310.57882-100000@InterJet.elischer.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
cc: arch@freebsd.org
cc: Poul-Henning Kamp <phk@phk.freebsd.dk>
Subject: Re: cvs commit: src/sys/kern kern_proc.c
X-BeenThere: freebsd-arch@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Discussion related to FreeBSD architecture
	<freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
	<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
	<mailto:freebsd-arch-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 09 Jun 2004 19:00:43 -0000



On Wed, 9 Jun 2004, Pawel Jakub Dawidek wrote:

> On Wed, Jun 09, 2004 at 11:23:48AM -0700, Julian Elischer wrote:
> +> I do actually agree that a general purpose reference counting 
> +> API is very difficult to use in every situation and that there 
> +> are situations where you just HAVE to roll your own..
> 
> Maybe we can use macros to do this, something like:
> 
> #define	REFCNT_MTX(foo, prefix, type, mtx_field, refcnt_field, destroy_func) \
> foo void								\
> prefix ## _hold(type *obj)						\
> {									\
> 									\
> 	mtx_lock(&obj->mtx_field);					\
> 	obj->refcnt_field++;						\
> 	mtx_unlock(&obj->mtx_field);					\
> }									\
> 									\
> foo void								\
> prefix ## _free(type *obj)						\
> {									\
> 	int refcnt;							\
> 									\
> 	mtx_lock(&obj->mtx_field);					\
> 	refcnt = --obj->refcnt_field;					\
> 	mtx_unlock(&obj->mtx_field);					\
> 	if (refcnt == 0)						\
> 		destroy_func(obj);					\
> }
> 
> And the same for REFCNT_ATOMIC() and REFCNT_SPIN()?
> 'foo' could be for example 'static' or 'static __inline'.


I certainly agree that there is the possibility that there may need to
be several kinds of refcounts..

there are also examples where several operations need to be done
"atomically" but only one of those operations is the reference count.
Such cases need a lock to be held anyhow. (or a critical section or 
something)
For these sorts of things plain increments and decrements would
suffice.

As I mentionned before, it is also tricky how one handles 
the freeing of a reference to an object 
when you are in some spinlock'd region or an interrupt handler..

These various cases may require reference counts of different types.