shared_ptr are unclearSection: 20.3.2.2.3 [util.smartptr.shared.dest] Status: NAD Submitter: United States Opened: 2017-02-03 Last modified: 2017-07-15
Priority: Not Prioritized
View all other issues in [util.smartptr.shared.dest].
View all issues with NAD status.
Discussion:
Addresses US 134The semantics for destroying the deleter and the control-block are unclear. In particular, it is not clear that we
guarantee a lack of race conditions destroying the control-block and deleter. Possible race-free implementations might
destroy the deleter after running d(p), and before giving up the weak reference held by this shared_ptr;
running the destructor for d only when the last weak_ptr is destroyed, potentially at a much later date,
but ensuring that d(p) completes before the shared_ptr gives up its weak reference; making a copy of
d in the destructor before manipulating the weak count, and then using this copy to run d(p), even while
the control-block could be concurrently reclaimed with an expiring weak_ptr in another thread. Note that this
may be related to LWG 2751. (Also, see the note in 20.11.2.2.10 p1 [util.smartptr.getdeleter])
Proposed change: Clarify that the shared_ptr weak ownership of the control block is released at the end of the
destructor, and not as the destructor begins. Otherwise, the deleter might be destroyed even before the destructor gets to
move a copy to call safely.
[2017-07 Toronto Thurs Issue Prioritization]
NAD; Alisdair to provide rationale
Proposed resolution: