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