cvs commit: src/sys/kern kern_proc.c

[Pawel Jakub Dawidek]

On Wed, Jun 09, 2004 at 04:39:37PM +0000, Bosko Milekic wrote:
+> 
+> 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.

But isn't you reference counting mechanism limited to only 0 and 1
values?

-- 
Pawel Jakub Dawidek                       http://www.FreeBSD.org
pjd at FreeBSD.org                           http://garage.freebsd.pl
FreeBSD committer                         Am I Evil? Yes, I Am!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/cvs-src/attachments/20040609/ec3b5c8a/attachment.bin