...

Yes, in that you can safely copy pointers in multiple threads at the same time, i.e. access to the reference count is thread-safe. No, in that you cannot use a single smart pointer object simultaneously from several threads.

The above two statements are conflicting. You say that access to reference count is thread safe but while access to shared_ptr from multiple threads is not thread safe. Then what is the benefit of it being thread safe if you cannot use it from multiple threads. Also being thread safe means read and write both are thread safe. So once you say that it is thread safe, then I assume that you mean both read and write are thread safe. In the above statements, is that what you mean? I am now even more confused about the thread safety of smart pointers. Could you please elaborate it more. Thanks a lot, Divick --- Sebastian Redl <sebastian.redl@getdesigned.at> wrote:

divick kishore wrote:

...

Hi, I have several questions related to boost.

1. Are boost::smart pointers thread safe especially shared_ptr ? Although it seems but I still want to be sure of that.

Yes, in that you can safely copy pointers in multiple threads at the same time, i.e. access to the reference count is thread-safe. No, in that you cannot use a single smart pointer object simultaneously from several threads.

...

2. Why isn't there two flavours of every smart pointers, one with multithread safety and one without. If one is using some smart pointers in non threaded mode, then still does one need to pay the penalty for exclusive access ?

First, because the synchronization overhead of the current shared_ptr is small enough that it's not a reason to worry in most situations. Second, because experience has shown that having different types with different thread safety rules leads to chaos. Code that is single-threaded now might not remain so in the future. How many uses of the single-threaded versions are you going to forget to change? What if you refactor the code into a library? Will all code that calls this library be single-threaded?

It's a tradeoff, and Boost chose to always be thread-safe.

Sebastian Redl _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org

http://lists.boost.org/mailman/listinfo.cgi/boost-users

__________________________________________________________ Yahoo! India Matrimony: Find your partner now. Go to http://yahoo.shaadi.com

divick kishore wrote:

...

...

Yes, in that you can safely copy pointers in multiple threads at the same time, i.e. access to the reference count is thread-safe. No, in that you cannot use a single smart pointer object simultaneously from several threads.

The above two statements are conflicting. You say that access to reference count is thread safe but while access to shared_ptr from multiple threads is not thread safe. Then what is the benefit of it being thread safe if you cannot use it from multiple threads.

No, they are not. You misunderstood the statements.

Also being thread safe means read and write both are thread safe. So once you say that it is thread safe, then I assume that you mean both read and write are thread safe. In the above statements, is that what you mean?

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.

I am now even more confused about the thread safety of smart pointers. Could you please elaborate it more.

In short, the smart_ptr<> class's thread safety is limited to the smart_ptr<> instances themselves, but not to the objects pointed to by the smart_ptr<> instances. Cheers, Freddie