Thread safety of smart pointers?
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. 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 ? What this means is that for example when one is using shared_ptr which I assume is implemented as counted pointer, any count increment or decrement has to be lock protected in multi-threaded case, which will be an overkill if one is using shared_ptr in a non multi-threaded code. 3. To enable multi-thread safety for other various libraries especially which are non-templates, does one need to compile boost with some special flags passed to the bjam? I am not sure whether this question is suited for this mailing list or not. Correct me if this is not the correct platform for posting this question. Thanks, Divick __________________________________________________________ Yahoo! India Matrimony: Find your partner now. Go to http://yahoo.shaadi.com
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
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:
I am now even more confused about the thread safety of smart pointers. Could you please elaborate it more.
Does http://boost.org/libs/smart_ptr/shared_ptr.htm#ThreadSafety help?
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
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
participants (4)
-
divick kishore -
Peter Dimov -
Sebastian Redl -
Wu Yinghui, Freddie