From: Ray Whitmer <ray@personallegal.net>

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.

[snip]

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.

Personally, I read this and said, "eeek!" (Well, not literally. My office mates would wonder what was up.) I think any design like this is going to be (at best) very non-portable, and (more likely) subject to breaking at the worst possible moment (i.e. when demonstrating to a customer). Is "relatively" thread-safe really good enough here? As a constructive suggestion, if you want to reduce lock conflicts in hash tables, have you considered some form of finer-grained locking? You could, for example, have one lock per "slot" in your hash table. Computing the hash and finding the slot is thread-safe (since it doesn't depend on the state of the hash table), so you could then lock only the slot itself while performing list maintenance or whatever you need to do to read/write the data. This would be truly thread-safe but might perform better if you have lots of simultaneous readers/writers. I haven't tested this, but if you do, I'd be interested to hear the results. Regards, - James PS - I'd be even more worried in Java, btw, since Java opcodes should map to CPU operations less well than a compiled binary. Not to mention that in Java, the portability assumption becomes really critical. Java classes are *supposed* to be portable.