<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>Issue 896: Library thread safety issue</title>
<meta property="og:title" content="Issue 896: Library thread safety issue">
<meta property="og:description" content="C++ library issue. Status: C++11">
<meta property="og:url" content="https://cplusplus.github.io/LWG/issue896.html">
<meta property="og:type" content="website">
<meta property="og:image" content="http://cplusplus.github.io/LWG/images/cpp_logo.png">
<meta property="og:image:alt" content="C++ logo">
<style>
  p {text-align:justify}
  li {text-align:justify}
  pre code.backtick::before { content: "`" }
  pre code.backtick::after { content: "`" }
  blockquote.note
  {
    background-color:#E0E0E0;
    padding-left: 15px;
    padding-right: 15px;
    padding-top: 1px;
    padding-bottom: 1px;
  }
  ins {background-color:#A0FFA0}
  del {background-color:#FFA0A0}
  table.issues-index { border: 1px solid; border-collapse: collapse; }
  table.issues-index th { text-align: center; padding: 4px; border: 1px solid; }
  table.issues-index td { padding: 4px; border: 1px solid; }
  table.issues-index td:nth-child(1) { text-align: right; }
  table.issues-index td:nth-child(2) { text-align: left; }
  table.issues-index td:nth-child(3) { text-align: left; }
  table.issues-index td:nth-child(4) { text-align: left; }
  table.issues-index td:nth-child(5) { text-align: center; }
  table.issues-index td:nth-child(6) { text-align: center; }
  table.issues-index td:nth-child(7) { text-align: left; }
  table.issues-index td:nth-child(5) span.no-pr { color: red; }
  @media (prefers-color-scheme: dark) {
     html {
        color: #ddd;
        background-color: black;
     }
     ins {
        background-color: #225522
     }
     del {
        background-color: #662222
     }
     a {
        color: #6af
     }
     a:visited {
        color: #6af
     }
     blockquote.note
     {
        background-color: rgba(255, 255, 255, .10)
     }
  }
</style>
</head>
<body>
<hr>
<p><em>This page is a snapshot from the LWG issues list, see the <a href="lwg-active.html">Library Active Issues List</a> for more information and the meaning of <a href="lwg-active.html#C++11">C++11</a> status.</em></p>
<h3 id="896"><a href="lwg-defects.html#896">896</a>. Library thread safety issue</h3>
<p><b>Section:</b> 20.3.2.2 <a href="https://wg21.link/util.smartptr.shared">[util.smartptr.shared]</a> <b>Status:</b> <a href="lwg-active.html#C++11">C++11</a>
 <b>Submitter:</b> Hans Boehm <b>Opened:</b> 2008-09-16 <b>Last modified:</b> 2016-01-28</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>View all other</b> <a href="lwg-index.html#util.smartptr.shared">issues</a> in [util.smartptr.shared].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#C++11">C++11</a> status.</p>
<p><b>Discussion:</b></p>
<p>
It is unclear whether <code>shared_ptr</code> is thread-safe in the sense that
multiple threads may simultaneously copy a <code>shared_ptr</code>.  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 <code>use_count</code> is not an
explicit field, and constructors and assignment take a const reference
to an existing <code>shared_ptr</code>.)
</p>

<p>
Pro thread-safety:
</p>
<p>
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.
</p>
<p>
Against thread-safety:
</p>
<p>
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.
</p>

<p><i>[
San Francisco:
]</i></p>


<blockquote>
<p>
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
</p>
<p>
Detlef: I think that <code>shared_ptr</code> should not be thread-safe.
</p>
<p>
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 <code>shared_ptr</code> to get at an
object.
</p>
<p>
Leave in Open. Detlef will submit an alternative proposed resolution
that makes <code>shared_ptr</code> explicitly unsafe.
</p>
<p>
A third option is to support both threadsafe and non-safe share_ptrs,
and to let the programmer decide which behavior they want.
</p>

<p>
Beman:  Peter, do you support the PR?
</p>

<p>
Peter:
</p>
<blockquote>
<p>
Yes, I support the proposed resolution, and I certainly oppose any
attempts to <code>make shared_ptr</code> thread-unsafe.
</p>
<p>
I'd mildly prefer if
</p>
<blockquote><p>
[<i>Note:</i> This is true in spite of that fact that such functions often
modify <code>use_count()</code> <i>--end note</i>]
</p></blockquote>
<p>
is changed to
</p>
<blockquote><p>
[<i>Note:</i> This is true in spite of that fact that such functions often
cause a change in <code>use_count()</code> <i>--end note</i>]
</p></blockquote>
<p>
(or something along these lines) to emphasise that <code>use_count()</code> is not,
conceptually, a variable, but a return value.
</p>
</blockquote>

</blockquote>

<p><i>[
2009-07 Frankfurt
]</i></p>


<blockquote>
<p>
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.
</p>
<p>
No concensus on that vote.
</p>
<p>
Hans to improve wording in consultation with Pete. Leave Open.
</p>
</blockquote>

<p><i>[
2009-10 Santa Cruz:
]</i></p>


<blockquote><p>
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.
</p></blockquote>

<p><i>[
2009-10-24 Hans adds:
]</i></p>


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

<p>
I suspect we really want to say something along the lines of:
</p>

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

<p>
But I think this needs further discussion by experts to make sure this
is right.
</p>

<p>
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.
</p>
</blockquote>

<p><i>[
2010-01-20 Howard:
]</i></p>


<blockquote>
<p>
I've moved Hans' suggested wording above into the proposed resolution section
and preserved the previous wording here:
</p>

<blockquote>
<p>
Make it explicitly thread-safe, in this weak sense, as I believe was intended:
</p>
<p>
Insert in 20.3.2.2 <a href="https://wg21.link/util.smartptr.shared">[util.smartptr.shared]</a>, before p5:
</p>
<blockquote>
<p>
For purposes of determining the presence of a data race,
member functions do not modify <code>const shared_ptr</code> and
const <code>weak_ptr</code> arguments, nor any objects they
refer to.  [<i>Note:</i> This is true in spite of that fact that such functions often
cause a change in <code>use_count()</code> <i>--end note</i>]
</p>
</blockquote>
<p>
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
<code>use_count()</code>.  I think Howard arrived at a similar conclusion.
</p>
</blockquote>
</blockquote>

<p><i>[
2010 Pittsburgh:  Moved to Ready for Pittsburgh
]</i></p>




<p id="res-896"><b>Proposed resolution:</b></p>

<p>
Insert a new paragraph at the end of 20.3.2.2 <a href="https://wg21.link/util.smartptr.shared">[util.smartptr.shared]</a>:
</p>

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





</body>
</html>
