<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<p>This smells fishy. Protecting a single store or a single load with a lock makes the memory access atomic, but it does not magically make it correct.</p>
<p>The lock means you won´t do undefined memory accesses (in theory), and won´t get half-updated values (in practice, on 32-bits platforms). The value itself will still change in fundamentally racy way.</p>
</blockquote>
<p>Very much agreed! There is an “TODO” attached to the associated message when sending the patch to the mailing-list:</p>
<pre><code>TODO: Instead of locking/unlocking the mutex each time we are interested in
reading/writing the value, we should use an atomic variable.</code></pre>
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<p>I know the problem predates (by very long) this patch. But at least, it is currently contained. I don´t think we should expose a fundamentally broken API.</p>
</blockquote>
<p>Yes, and I plan to spend more time working on that at a later time (unless someone beats me to it). I was focusing on what is practically broken with these patches, though (as stated) I 100% agree with you.</p>