diff options
Diffstat (limited to '_posts/2015-07-03-std-call-once-bug-in-visual-studio-2012-2013.md')
| -rw-r--r-- | _posts/2015-07-03-std-call-once-bug-in-visual-studio-2012-2013.md | 54 |
1 files changed, 26 insertions, 28 deletions
diff --git a/_posts/2015-07-03-std-call-once-bug-in-visual-studio-2012-2013.md b/_posts/2015-07-03-std-call-once-bug-in-visual-studio-2012-2013.md index 39fd93a..2b11d54 100644 --- a/_posts/2015-07-03-std-call-once-bug-in-visual-studio-2012-2013.md +++ b/_posts/2015-07-03-std-call-once-bug-in-visual-studio-2012-2013.md @@ -14,31 +14,30 @@ Library implementation shipped with Microsoft Visual Studio 2012/2013. This post, including code samples, is licenced under the terms of the MIT License. -See -[LICENSE.txt](https://github.com/egor-tensin/cpp-notes/blob/gh-pages/LICENSE.txt) -for details. +See [LICENSE.txt] for details. + +[LICENSE.txt]: https://github.com/egor-tensin/cpp-notes/blob/gh-pages/LICENSE.txt ## Introduction I've recently come across a nasty standard library bug in the implementation shipped with Microsoft Visual Studio 2012/2013. -[StackOverflow](https://stackoverflow.com) -was of -[no help](https://stackoverflow.com/questions/26477070/concurrent-stdcall-once-calls), -so I had to somehow report the bug to the maintainers. -Oddly enough, Visual Studio's -[Connect page](https://connect.microsoft.com/VisualStudio) -wouldn't let me to report one, complaining that I supposedly had no right to do -so, even though I was logged in from my work account, associated with my Visual -Studio 2013 installation. +[StackOverflow was of no help], so I had to somehow report the bug to the +maintainers. +Oddly enough, Visual Studio's [Connect page] wouldn't let me to report one, +complaining that I supposedly had no right to do so, even though I was logged +in from my work account, associated with my Visual Studio 2013 installation. Fortunately, I've come across the personal website of this amazing guy, -[Stephan T. Lavavej](http://nuwen.net/stl.html), -who appears to be the chief maintainer of Microsoft's standard library -implementation. +[Stephan T. Lavavej], who appears to be the chief maintainer of Microsoft's +standard library implementation. He seems to be your go-to guy when it comes to obvious standard library misbehaviours. +[StackOverflow was of no help]: https://stackoverflow.com/questions/26477070/concurrent-stdcall-once-calls +[Connect page]: https://connect.microsoft.com/VisualStudio +[Stephan T. Lavavej]: http://nuwen.net/stl.html + ## C++11 and singletons Anyway, the story begins with me trying to implement the singleton pattern @@ -98,10 +97,8 @@ private: }; {% endhighlight %} -Note that the -[N2660](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2660.htm) -standard proposal isn't/wasn't implemented in the compilers shipped with Visual -Studio 2012/2013. +Note that the [N2660] standard proposal isn't/wasn't implemented in the +compilers shipped with Visual Studio 2012/2013. If it was, I wouldn't, of course, need to employ this `std::call_once` trickery, and the implementation would be much simpler, i.e. something like this: @@ -133,15 +130,16 @@ the instance has already been intialized. This other thread might then return a reference to the instance which hasn't completed its initialization and is most likely unsafe to use.</p> -<p>Since C++11 includes the proposal for -<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2660.htm">"Dynamic Initialization and Destruction with Concurrency"</a> -mentioned above, this routine would indeed be thread-safe in C++11. +<p>Since C++11 includes the proposal mentioned above, this routine would indeed +be thread-safe in C++11. Unfortunately, the compilers shipped with Visual Studio 2012/2013 don't/didn't implement this particular proposal, which caused me to turn my eyes to <code>std::call_once</code>, which seems to implement exactly what I needed.</p> </div> +[N2660]: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2660.htm + ## The bug Unfortunately, matters became a bit more complicated when I tried to have two @@ -279,15 +277,15 @@ So it appears that the implementation of `std::call_once` shipped with Visual Studio 2012/2013 relies on some kind of a global lock, which causes even the simple example above to misbehave. -The complete code sample to demonstrate the misbehaviour described above can be -found at -[https://github.com/egor-tensin/cpp-notes/tree/gh-pages/src/posts/std_call_once_bug_in_visual_studio_2012_2013](https://github.com/egor-tensin/cpp-notes/tree/gh-pages/src/posts/std_call_once_bug_in_visual_studio_2012_2013). +The [complete code] sample to demonstrate the misbehaviour described above can +be found in the blog's repository. + +[complete code]: https://github.com/egor-tensin/cpp-notes/tree/gh-pages/src/posts/std_call_once_bug_in_visual_studio_2012_2013 ## Resolution -So, since I couldn't submit the bug via Visual Studio's -[Connect page](https://connect.microsoft.com/VisualStudio), -I wrote to Mr. Lavavej directly, not hoping for an answer. +So, since I couldn't submit the bug via Visual Studio's [Connect page], I wrote +to Mr. Lavavej directly, not hoping for an answer. Amazingly, it took him less than a day to reply. He told me he was planning to overhaul `std::call_once` for Visual Studio 2015. Meanwhile, I had to stick to something else; I think I either dropped logging |