From owner-freebsd-arch Mon Nov 12 16: 0:39 2001 Delivered-To: freebsd-arch@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id 75DE337B41C; Mon, 12 Nov 2001 16:00:32 -0800 (PST) Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id PAA95502; Mon, 12 Nov 2001 15:53:29 -0800 (PST) Date: Mon, 12 Nov 2001 15:53:28 -0800 (PST) From: Julian Elischer To: John Baldwin Cc: Matthew Dillon , freebsd-arch@FreeBSD.ORG, Robert Watson , Terry Lambert Subject: Re: cur{thread/proc}, or not. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 we should re-examine teh 'refcount' API it's a very basic type and gettin gmore-so all the time.. we can affort to have a 'standard' 'safe' way of doing reference counts. On Mon, 12 Nov 2001, John Baldwin wrote: > > On 12-Nov-01 Matthew Dillon wrote: > >:The point is that if the credentials are granted, then a > >:change in credential is not a change of the credential itself, > >:but is instead a copy-on-write proposition. In other words, > >:credentials, once granted, are priviledge stable. > >: > >:If this is the case, then they are written when they are > >:instanced, cloned before they are modified (indeed, it seems > >:that the clone/modify operation must be made atomic), and > >:thus are never written once instanced -- only destroyed on > >:the 1->0 reference transition. > >: > >:If so, then no locking is required, since the LCK CMPXCHG can > >:be utilized to do atomic increment and decrement on the > >:reference counting, without needing locks. > >:... > >: > >:-- Terry > > > > Yes, I believe this is how credentials work. I looked at > > the code about 6 months ago. We should not have to do any > > locking of the credential stuff, only simple mutexing > > around the ref counter. That is how it should work > > is how I believe it currently works. > > 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/ > 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 > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message