Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 31 Oct 2000 11:52:26 -0800
From:      Alfred Perlstein <bright@wintelcom.net>
To:        Frank Mayhar <frank@exit.com>
Cc:        John Baldwin <jhb@FreeBSD.ORG>, Cedric Berger <cedric@wireless-networks.com>, freebsd-smp@FreeBSD.ORG, Robert Watson <rwatson@FreeBSD.ORG>
Subject:   Re: Reference count invariants in a fine-grained threaded enviro
Message-ID:  <20001031115226.X22110@fw.wintelcom.net>
In-Reply-To: <200010311923.e9VJNG309763@realtime.exit.com>; from frank@exit.com on Tue, Oct 31, 2000 at 11:23:16AM -0800
References:  <XFMail.001031111514.jhb@FreeBSD.org> <200010311923.e9VJNG309763@realtime.exit.com>

next in thread | previous in thread | raw e-mail | index | archive | help
* Frank Mayhar <frank@exit.com> [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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20001031115226.X22110>