Subj : Re: full-blown experiential smr-based reference counted pointer impl...
To   : comp.programming.threads
From : Chris Thomasson
Date : Fri Apr 01 2005 06:17 am

>>> Yes, you wouldn't use SMR for everything but there are definitely niche
>>> uses for it so it doesn't hurt to have it around.
>>
>> True...
>>
> In the sense that atomic_ptr and RCU have niche uses.  They have different
> strengths.  SMR has better granularity than a proxy GC like RCU.  So for
> situations like where a thread holds a reference for a relatively long 
> time,
> SMR is better than RCU since it won't tie up a lot of resources waiting to
> be released.  But it probably doesn't scale as well under certain 
> conditions.

That's why I implemented an experiential reference count api. It uses SMR to 
protect the actual counts. Instead of guarding long lasting objects with a 
hazard pointer, I protected them with a normal single-word reference count. 
That way the hazard pointer, and the overhead that comes with it, will not 
be tied to the objects lifetime; you only have a static amount of hazard 
pointers per-thread. Also, once you go through the expensive process of 
copying a shared pointer to a local pointer, you only have to rely on simple 
atomic inc's and dec's, no "expensive SMR api's" on local pointer 
accesses...




> Even mutexes have niche uses.  There are situations where they'll work
> better than lock-free solutions.

Yes. I am finding that a marriage between lock-free and an "existing 
portable" lock-based synchronization api's can be very useful. Like the 
portable eventcount I did. It uses pthread mutex/cond to manage all of its 
slow paths. It seems that calls to pthread_xxx functions can be 
unnecessarily expensive, no matter what OS. So, I find that using lock-free 
to skip calls into pthread_xxx is usually beneficial to performance...

.