Movatterモバイル変換

This page is a snapshot from the LWG issues list, see theLibrary Active Issues List for more information and the meaning ofC++11 status.

896. Library thread safety issue

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

Priority:Not Prioritized

View all otherissues in [util.smartptr.shared].

View all issues withC++11 status.

Discussion:

It is unclear whethershared_ptr is thread-safe in the sense thatmultiple threads may simultaneously copy ashared_ptr. However thisis a critical piece of information for the client, and it has significantimpact on usability for many applications. (Detlef Vollman thinks itis currently clear that it is not thread-safe. Hans Boehm thinksit currently requires thread safety, since theuse_count is not anexplicit field, and constructors and assignment take a const referenceto an existingshared_ptr.)

Pro thread-safety:

Many multi-threaded usages are impossible. A thread-safe version canbe used to destroy an object when the last thread drops it, somethingthat 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, evenif used by a single thread. Many applications, including all single-threadedones, do not care.

[San Francisco:]

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

Detlef: I think thatshared_ptr should not be thread-safe.

Hans: When you create a thread with a lambda, it in some cases makes itvery difficult for the lambda to reference anything in the heap. It'scurrently ambiguous as to whether you can use ashared_ptr to get at anobject.

Leave in Open. Detlef will submit an alternative proposed resolutionthat makesshared_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 anyattempts tomake shared_ptr thread-unsafe.

I'd mildly prefer if

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

is changed to

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

(or something along these lines) to emphasise thatuse_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, onewould 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 tomake it clear that the portion after the first comma only applies forthe presence of data races.

[2009-10-24 Hans adds:]

I think we need to pull 896 back from ready, unfortunately. My wordingdoesn'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, memberfunctions access and modify only theshared_ptr andweak_ptr objects themselves and not objects they refer to.Changes inuse_count() do not reflect modifications that canintroduce data races.

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

Detlef and I agree continue to disagree on the resolution, but I thinkwe agree that it would be good to try to expedite this so that it can bein 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 itwould be good to look at this between meetings.

[2010-01-20 Howard:]

I've moved Hans' suggested wording above into the proposed resolution sectionand 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 modifyconst shared_ptr andconstweak_ptr arguments, nor any objects theyrefer to. [Note: This is true in spite of that fact that such functions oftencause a change inuse_count()--end note]

On looking at the text, I'm not sure we need a similar disclaimeranywhere else, since nothing else has the problem with the modifieduse_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 accessand modify only theshared_ptr andweak_ptr objects themselvesand not objects they refer to. Changes inuse_count() do not reflectmodifications that can introduce data races.