Boost logo

Boost Users :

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:


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.


Ray Whitmer

Boost-users list run by williamkempf at, kalb at, bjorn.karlsson at, gregod at, wekempf at