Thread safety of smart pointers?

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Thread safety of smart pointers?

divick kishore
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
_______________________________________________
Boost-users mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|

Re: Thread safety of smart pointers?

Sebastian Redl
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
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|

Re: Thread safety of smart pointers?

divick kishore
>> 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 <[hidden email]>
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
> [hidden email]
>
http://lists.boost.org/mailman/listinfo.cgi/boost-users
>



               
__________________________________________________________
Yahoo! India Matrimony: Find your partner now. Go to http://yahoo.shaadi.com
_______________________________________________
Boost-users mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|

Re: Thread safety of smart pointers?

Peter Dimov
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?
_______________________________________________
Boost-users mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|

Re: Thread safety of smart pointers?

Wu Yinghui, Freddie
In reply to this post by divick kishore
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

_______________________________________________
Boost-users mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/boost-users

yhwu.vcf (798 bytes) Download Attachment
signature.asc (195 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Thread safety of smart pointers?

Sebastian Redl
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
_______________________________________________
Boost-users mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/boost-users