This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of CD1 status.
Section: 20.3.2.2.6 [util.smartptr.shared.obs], 99 [tr.util.smartptr.shared.obs] Status: CD1 Submitter: Martin Sebor Opened: 2005-10-18 Last modified: 2016-01-28
Priority: Not Prioritized
View all other issues in [util.smartptr.shared.obs].
View all issues with CD1 status.
Discussion:
Peter Dimov wrote: To: C++ libraries mailing list Message c++std-lib-15614 [...] The intent is for both use_count() and unique() to work in a threaded environment. They are intrinsically prone to race conditions, but they never return garbage.
This is a crucial piece of information that I really wish were captured in the text. Having this in a non-normative note would have made everything crystal clear to me and probably stopped me from ever starting this discussion :) Instead, the sentence in p12 "use only for debugging and testing purposes, not for production code" very strongly suggests that implementations can and even are encouraged to return garbage (when threads are involved) for performance reasons.
How about adding an informative note along these lines:
Note: Implementations are encouraged to provide well-defined behavior for use_count() and unique() even in the presence of multiple threads.
I don't necessarily insist on the exact wording, just that we capture the intent.
Proposed resolution:
Change 20.3.2.2.6 [util.smartptr.shared.obs] p12:
[Note:
use_count()is not necessarily efficient.Use only for debugging and testing purposes, not for production code.--end note]
Change 20.3.2.3.6 [util.smartptr.weak.obs] p3:
[Note:
use_count()is not necessarily efficient.Use only for debugging and testing purposes, not for production code.--end note]