896. Library thread safety issue

Section: 20.3.2.2 [util.smartptr.shared] Status: C++11 Submitter: Hans Boehm Opened: 2008-09-16 Last modified: 2016-01-28

Priority: Not Prioritized

View all other issues in [util.smartptr.shared].

View all issues with C++11 status.

Discussion:

It is unclear whether shared_ptr is thread-safe in the sense that multiple threads may simultaneously copy a shared_ptr. However this is a critical piece of information for the client, and it has significant impact on usability for many applications. (Detlef Vollman thinks it is currently clear that it is not thread-safe. Hans Boehm thinks it currently requires thread safety, since the use_count is not an explicit field, and constructors and assignment take a const reference to an existing shared_ptr.)

Pro thread-safety:

Many multi-threaded usages are impossible. A thread-safe version can be used to destroy an object when the last thread drops it, something that is often required, and for which we have no other easy mechanism.

Against thread-safety:

The thread-safe version is well-known to be far more expensive, even if used by a single thread. Many applications, including all single-threaded ones, do not care.

[ San Francisco: ]

Beman: this is a complicated issue, and would like to move this to Open and await comment from Peter Dimov; we need very careful and complete rationale for any decision we make; let's go slow

Detlef: I think that shared_ptr should not be thread-safe.

Hans: When you create a thread with a lambda, it in some cases makes it very difficult for the lambda to reference anything in the heap. It's currently ambiguous as to whether you can use a shared_ptr to get at an object.

Leave in Open. Detlef will submit an alternative proposed resolution that makes shared_ptr explicitly unsafe.

A third option is to support both threadsafe and non-safe share_ptrs, and to let the programmer decide which behavior they want.

Beman: Peter, do you support the PR?

Peter:

Yes, I support the proposed resolution, and I certainly oppose any attempts to make shared_ptr thread-unsafe.

I'd mildly prefer if

[Note: This is true in spite of that fact that such functions often modify use_count() --end note]

is changed to

[Note: This is true in spite of that fact that such functions often cause a change in use_count() --end note]

(or something along these lines) to emphasise that use_count() is not, conceptually, a variable, but a return value.

[ 2009-07 Frankfurt ]

Vote: Do we want one thread-safe shared pointer or two? If two, one would allow concurrent construction and destruction of shared pointers, and one would not be thread-safe. If one, then it would be thread-safe.

No concensus on that vote.

Hans to improve wording in consultation with Pete. Leave Open.

[ 2009-10 Santa Cruz: ]

Move to Ready. Ask Editor to clear up wording a little when integrating to make it clear that the portion after the first comma only applies for the presence of data races.

[ 2009-10-24 Hans adds: ]

I think we need to pull 896 back from ready, unfortunately. My wording doesn't say the right thing.

I suspect we really want to say something along the lines of:

For purposes of determining the presence of a data race, member functions access and modify only the shared_ptr and weak_ptr objects themselves and not objects they refer to. Changes in use_count() do not reflect modifications that can introduce data races.

But I think this needs further discussion by experts to make sure this is right.

Detlef and I agree continue to disagree on the resolution, but I think we agree that it would be good to try to expedite this so that it can be in CD2, since it's likely to generate NB comments no matter what we do. And lack of clarity of intent is probably the worst option. I think it would be good to look at this between meetings.

[ 2010-01-20 Howard: ]

I've moved Hans' suggested wording above into the proposed resolution section and preserved the previous wording here:

Make it explicitly thread-safe, in this weak sense, as I believe was intended:

Insert in 20.3.2.2 [util.smartptr.shared], before p5:

For purposes of determining the presence of a data race, member functions do not modify const shared_ptr and const weak_ptr arguments, nor any objects they refer to. [Note: This is true in spite of that fact that such functions often cause a change in use_count() --end note]

On looking at the text, I'm not sure we need a similar disclaimer anywhere else, since nothing else has the problem with the modified use_count(). I think Howard arrived at a similar conclusion.

[ 2010 Pittsburgh: Moved to Ready for Pittsburgh ]

Proposed resolution:

Insert a new paragraph at the end of 20.3.2.2 [util.smartptr.shared]:

For purposes of determining the presence of a data race, member functions access and modify only the shared_ptr and weak_ptr objects themselves and not objects they refer to. Changes in use_count() do not reflect modifications that can introduce data races.