https://svn.boost.org/trac10/ticket/13309 <p> The discussion in the git review <a class="ext-link" href="https://github.com/boostorg/filesystem/pull/59#discussion_r152524074"><span class="icon">​</span>https://github.com/boostorg/filesystem/pull/59#discussion_r152524074</a> showed that the implementations of <code>function_address_holder::get_module</code> and <code>function_address_holder::get</code> are not completely atomic, because the loop conditions </p> <pre class="wiki">for(unsigned i = 0; ModuleStates[id] &lt; 2; ++i){ </pre><p> and </p> <pre class="wiki">for(unsigned i = 0; FunctionStates[id] &lt; 2; ++i){ </pre><p> are not using a read barrier for the variables <code>ModuleStates[id]</code> and <code>FunctionStates[id]</code>. </p> <p> It seems that proper thread-safety using interlocked operations could be realized by emulating an interlocked read-acquire operation via the <code>BOOST_INTERLOCKED_COMPARE_EXCHANGE(&amp;N, 0, 0)</code> idiom. </p> <p> I can make a concrete pull request if agreement exists on the approach </p> en-us /htdocs/site/boost.png https://svn.boost.org/trac10/ticket/13309 Trac 1.4.3 Daniel Krügler <daniel.kruegler@…> Wed, 22 Nov 2017 22:36:40 GMT https://svn.boost.org/trac10/ticket/13309#comment:1 https://svn.boost.org/trac10/ticket/13309#comment:1 <ul> <li><strong>owner</strong> set to <span class="trac-author">Ion Gaztañaga</span> </li> <li><strong>component</strong> <span class="trac-field-old">None</span> → <span class="trac-field-new">interprocess</span> </li> </ul> <p> The relevant file is <code>boost/interprocess/detail/win32_api.hpp</code> </p> Ticket