Messages in this thread | | | From | Joe Seigh <> | Subject | rcuref optimization | Date | Wed, 21 Dec 2005 13:35:12 -0500 |
| |
You can get rid of the requirement for atomic_inc_not_zero logic if you use the logic I first proposed here in c.l.c++.m. http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&selm=3E7C83DD.B126DE24%40xemaps.com for weakptrs where the same kind of logic was required for the strong count. This will allow you to use fetch_inc (e.g. LOCK INC on x86) instead of compare and swap logic which might be more efficient on some processors. You might even be able to get rid of the the "unincrement" if you are pretty sure the maximum number of increments won't put the refcount to zero.
Summary for those who can't follow the link. Basically, if you decrement the refcount to zero, you attempt to set the refcount to the minimum signed value (e.g. 0x80000000 for 32 bits). If successful you can schedule the object for deallocation using RCU. If unsuccessful, some other thread has incremented the refcount and object is still in use and even deallocated by some other thread. Incrementing of the refcount is only considered successful if the result is greater than zero. If less than zero, object is being scheduled for deallocation.
-- Joe Seigh
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |