Date: Fri, 13 Mar 2015 16:58:38 -0700 From: John-Mark Gurney <jmg@funkthat.com> To: Mateusz Guzik <mjguzik@gmail.com> Cc: freebsd-arch@freebsd.org Subject: Re: refcount_release_take_##lock Message-ID: <20150313235838.GM32288@funkthat.com> In-Reply-To: <20150313231607.GB32157@dft-labs.eu> References: <20141025184448.GA19066@dft-labs.eu> <201410281413.58414.jhb@freebsd.org> <20141028193404.GB12014@dft-labs.eu> <201411111427.15407.jhb@freebsd.org> <20150313231607.GB32157@dft-labs.eu>
next in thread | previous in thread | raw e-mail | index | archive | help
Mateusz Guzik wrote this message on Sat, Mar 14, 2015 at 00:16 +0100:
> In the meantime I wrote a new version.
>
> Apart from locking-handling primitives this time we get
> refcount_acquire_if_greater and refcount_release_if_greater helpers.
I don't see how this is of any benefit... The smallest value you can
provide is 0, which means the only time a reference can be obtained is
if the caller already has a reference. If you don't have a reference
(making it =0), it isn't safe to call this function on the object, as
it could be free'd, and point to a different type of object... Even if
you implement type-safe memory (which we shouldn't use more of), it's
less than ideal, since you then have to check if the object is the same
object you were expecting, and need to release it...
The release_if is even more problematic IMO...
After reading the previous discussion, I really don't like this. If
this gets approved (others override my objection), we need some docs
that say this should never be used, and it's use is only in the unsafe
case where the containing data structure does NOT have a reference to
the object.
--
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150313235838.GM32288>