|
Boost : |
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk