Re: [boost] [thread] thread_specific_ptr leaks on VS2012 when using std::async()

Subject: Re: [boost] [thread] thread_specific_ptr leaks on VS2012 when using std::async()
From: Klaim - Joël Lamotte (mjklaim_at_[hidden])
Date: 2013-03-04 18:38:40

Before answering, I need to point this: I sent this problem MS and
apparently there is a bug that will be fixed in future STL versions of
Visual Studio.
See:
http://connect.microsoft.com/VisualStudio/feedback/details/761209/boost-thread-specific-ptr-leaks-on-vs2012-when-using-std-async
 "Hi,

 Thanks for reporting this bug. We've fixed it, and the fix will be
available in the next release of our C++ Standard Library implementation.

 The problem was that constructing a std::thread initialized an
"at_thread_exit_mutex", which was never destroyed. We've added an atexit()
call to clean up this mutex, and we've additionally changed std::mutex and
std::condition_variable's internal allocations to be marked as "CRT
blocks", which prevents them from being reported as leaks by the CRT's
leak-tracking machinery.

 Note: Connect doesn't notify me about comments. If you have any further
questions, please E-mail me.

 Stephan T. Lavavej
 Senior Developer - Visual C++ Libraries
 stl_at_[hidden]"

On Mon, Mar 4, 2013 at 11:46 PM, Vicente J. Botet Escriba <
vicente.botet_at_[hidden]> wrote:

>
> Shouldn't the future destructor synchronize with the hidden thread used by
> std::async()?
>
>
This document (
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3451.pdf ) says:

"Practical field experience with futures has demonstrated one major
problem, which was discussed in
May 2012 at the SG1 meeting in Bellevue.

~future/~shared_future Must Never Block
“Blocking is evil.” – Various

The good news is that the Standard’s specification of future and
shared_future destructors specifies that
they never block. This is vital.
The bad news is that the Standard specifies that the associated state of an
operation launched by
std::async (only!) does nevertheless cause future destructors to block.
This is very bad for several
reasons, three of which are summarized below in rough order from least to
most important.

Example 1: Consistency

First, consider these two pieces of code:
// Example 1
// (a)                                // (b)
{                                      {
     async( []{ f(); } );                  auto f1 = async( []{ f(); } );
     async( []{ g(); } );                 auto f2 = async( []{ g(); } );
}                                       }

Users are often surprised to discover that (a) and (b) do not have the same
behavior, because normally
we ignore (and/or don’t look at) return values if we end up deciding we’re
not interested in the value
and doing so does not change the meaning of our program.
The two cannot have the same behavior if ~future joins."

So I think you are right, the future's destructor should have been blocking
when using async().
However, Herb Sutter commented on this document and the Visual Studio
implementation on his blog:

Question:
http://herbsutter.com/2013/01/15/videos-panel-and-c-concurrency/#comment-8100

"In September 2012 you posted a paper discussing the problems in the
present standard, with a blocking ~future(). In my experiments I have found
that it does no block! (VS 2012 – update 1)
Has the standard already been revised? Nice, but I would’ve thought that
the standard was already carved into stone? Shed some light, anyone?
"

Answer:
http://herbsutter.com/2013/01/15/videos-panel-and-c-concurrency/#comment-8131

"@Adam H: Right, VS 2012 is knowingly (temporarily) non-conforming on the
~future blocking issue in part because we knew this question is being
actively reviewed in the committee and we feel the status quo is harmful to
our customers. Of course, if the committee’s decision is to stay with the
C++11 rules we’ll change our implementation to conform and have to do more
to educate customers about the issue.

If the view that this should be fixed prevails in the committee, we’ll look
like geniuses for getting it “right” sooner, otherwise we’ll conform and
look like doofuses for shipping with another bug we had to go back and fix.

(We don’t do this often! Usually the right thing to do is just conform to
the standard, perceived bugs and all. But this bug is bad and under
discussion at the last two SG1 meetings…)"

Which basically mean it's VS2012 not following the standard on this
specific rule.

I had to find again these data I read before to answer your question, but I
might have missed data or understanding.
Does it help?

Joel Lamotte