[Boost-users] Thread-safe smart pointers, hashtables without locking

From: Ray Whitmer (ray_at_[hidden])
Date: 2006-05-03 18:20:44

I found the boost libraries and templates as I was looking for thread- 
safe smart pointers.  I was unable to use shared_ptr because I needed  
to be able to reconstitute a smart pointer from a raw pointer at any  
time without losing the count, so the count needs to be internal to  
the object, not external, so I am using intrusive_ptr.

Since I need my intrusive_ptr to be thread-safe, I included:

#include "boost/detail/atomic_count.hpp"

and then I declared my internal count to be of type:

boost::detail::atomic_count

which I then increment and decrement using the defined thread-safe  
operators from the add_ref and release methods, which should give me  
a relatively-thread-safe smart pointer with an internal count without  
having to do any actual locking.

This already seems like I may be going beyond the official interface  
by explicitly relying on something in the boost detail directory.  Is  
it wrong to rely on this?

But what I need now goes a bit further.  I need a hashtable for which  
lookups are thread-safe without doing any locking.  I only want to  
lock for adding or removing to/from the table.

I already have the hashtable implementation that does this that I  
have used in Java for quite a while.  In Java, I assumed the writing  
of a 32-bit reference into the hashtable array (or a null) was fairly  
atomic (which seemed reasonable on a 32-bit machine with normal  
alignment, etc).  I made sure in the implementation that a writer who  
locks and changes the hashtable never temporarily places the  
hashtable into a state where it cannot be correctly read by any non- 
locking reader.

I am hoping this will continue to work in C++ with the intrusive_ptr  
array of a hashtable.  intrusive_ptr seems to contain a single 32-bit  
value which is likely to be atomic, at least as long as I avoid 16- 
bit architectures.  Is there any better way to guarantee this?

With the exception of the reference count, the objects being kept by  
the hashtable are read-only, so this should allow me any number of  
threads simultaneously operating on the same massive shared data  
hashtables (which can get cleaned up when no longer in use, by  
looking at ref counts).

I am just posting here to see if anyone knows of a missed trick or  
bad assumption I have made here using these or other boost mechaniisms.

Is the thread-safe hashtable that does not require locking for  
reading something that many others would benefit from?  It is quite a  
simple implementation.

Thanks,

Ray Whitmer