Wu Yinghui, Freddie wrote:
What that reply meant was as following: - You may safely manipulate the smart_ptr<> instance itself, including modification to the reference count; - You may not safely use the object pointed to by the smart_ptr<> instance, if that object is not thread-safe.
Although the OP indeed misunderstood my statements, this is not what I meant either. My statements must have been poorly formulated to get two incorrect interpretations. What I meant was: - You may concurrently manipulate two distinct shared_ptr instances that point to the same object. In naive implementations, this would have a chance of trashing the reference count, thus leading to premature or deletion or no deletion at all. - You may NOT concurrently manipulate a single shared_ptr instance, i.e. assign to it, as this has a chance of trashing the pointers contained. (The result would be that one thread deletes the object, but before it can set the pointer to null or a newly allocated object, the other thread attempts to access the now-delete object.) shared_ptr makes no concurrency guarantees about the pointee. Access to the pointee is a simple read operation, which by itself can be done in as many threads at the same time as you want, but it is up to the pointee to synchronize incoming calls as necessary. Sebastian Redl