From owner-freebsd-smp Tue Oct 31 11:52:34 2000 Delivered-To: freebsd-smp@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id C31B637B4C5; Tue, 31 Oct 2000 11:52:31 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id e9VJqQY04138; Tue, 31 Oct 2000 11:52:26 -0800 (PST) Date: Tue, 31 Oct 2000 11:52:26 -0800 From: Alfred Perlstein To: Frank Mayhar Cc: John Baldwin , Cedric Berger , freebsd-smp@FreeBSD.ORG, Robert Watson Subject: Re: Reference count invariants in a fine-grained threaded enviro Message-ID: <20001031115226.X22110@fw.wintelcom.net> References: <200010311923.e9VJNG309763@realtime.exit.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: <200010311923.e9VJNG309763@realtime.exit.com>; from frank@exit.com on Tue, Oct 31, 2000 at 11:23:16AM -0800 Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org * Frank Mayhar [001031 11:23] wrote: > John Baldwin wrote: > > They don't. The ia64 has a 'fetchadd' instruction, but x86 and alpha don't > > have instructions for this, AFAIK. You can implement it using the > > atomic_cmpset() functions however. Of course, what happens if you decrement > > a reference and while you are freeing the object someone else obtains a > > reference to it? Granted, this shouldn't be possible since if no one can > > get to an object, no one should be able to find the object to allocate a > > reference to it.... > > This kind of thing is indeed the gotcha. It takes thinking the problem out > well and careful coding to avoid. Of course, avoiding a lock where possible > is almost always a win. I've already explained that this case is handled simply by using a lock in the parent! This error can't happen, it would be a severe error to free/destroy a struct proc twice, hence there should already be locking over the ucred pointer in the struct proc through this 'object'. If you think about it, with either atomic_t or mutexes this must be true (implicit mutual exclusion through a single reference point) or you're going to have problems. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message