Date: Wed, 9 Jun 2004 16:39:37 +0000 From: Bosko Milekic <bmilekic@FreeBSD.org> To: Nate Lawson <nate@root.org> Cc: "M. Warner Losh" <imp@bsdimp.com> Subject: Re: cvs commit: src/sys/kern kern_proc.c Message-ID: <20040609163937.GA26656@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
Nate Lawson wrote:
>Bosko wrote:
>> MEXT_REM_REF(m); /* Atomic decrement of m->m_ext.ref_cnt */
>> if (atomic_cmpset_int(m->m_ext.ref_cnt, 0, 1)) {
>> /* Do the free here... */
>> }
>> return;
>
>This may have a race unless the refcount increment path is done correctly:
>
>1:atomic_int--
>1:atomic_cmpset_int == 0 (yes, get ready to free it)
>
>2:atomic_cmpset_int == 0 (yes, object was in process of teardown)
>2:create new object, refcount = 1
>
>This assumes it's ok to have two objects of the same type in existence at
>the same time also (one being torn down while the other is created). Code
>that accesses an object must make sure it's locked separately.
>
>-Nate
No, that's not true. The scenario you describe cannot occur. The code
I posted prevents you from racing on teardown, so that you never have
two threads tearing down the same object. This is because the first
one to get to the cmpset will see the refcount to be zero and set it
up to 1 (atomically), so that the second thread will see it at 1 and
not do the destruction/free as well.
There is no race on the reference going back up once it's hit zero
because that would imply that we (who have sent it to zero) are now
somehow magically making it gain a reference.
Think about it, there is no race above.
-Bosko
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040609163937.GA26656>
