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: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2013-03-05 07:04:05

Le 05/03/13 00:38, Klaim - Joël Lamotte a écrit :
> 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?
>
>
Yes, I'm aware of Herb desiderata. Anyway C++11 has been released with 
these kind of futures blocking on the destructor. IMHO, MSVC should fix 
this issue.

Best,
Vicente