<p><pre><code>  &gt; How did you get into such issues? Were there classes where you got started, or was it all on the job?
</code></pre>
I took the usual college classes dealing with concurrency (in my school it was in the OS class), but it took several years in the industry to really feel confident with threads (it took less time to feel confident with networking). I wrote down my knowledge (for what it&#x27;s worth) in this book: <a href="http:&#x2F;&#x2F;www.amazon.com&#x2F;dp&#x2F;0996193308" rel="nofollow">http:&#x2F;&#x2F;www.amazon.com&#x2F;dp&#x2F;0996193308</a><p><pre><code>  &gt;  I&#x27;m not sure how you would move lock&#x2F;unlock pairs to the top of a file from different functions&#x2F;scopes.
</code></pre>
That solution might not work in every case. It worked in the particular case I was referring to.<p><pre><code>  &gt; It&#x27;s more about a codebase that&#x27;s almost perfectly right, but where I&#x27;m scared to change anything because I don&#x27;t have a big-picture model of the concurrency in my head..
</code></pre>
Hmmmmm, that&#x27;s an interesting question. Usually when the codebase is written, the person who wrote it had an idea in his head that, &quot;this is how things will be locked to avoid problems.&quot; I try to figure out what that idea was.<p>Sometimes there is like a critical &#x27;zone,&#x27; where a thread acquires the lock when it enters, and releases when it leaves. For example, it could acquire the lock when it enters a class method, and releases it when it leaves the class. Then the class becomes the critical zone.<p>Maybe learning to think of &#x27;critical zones&#x27; is the most important skill to understanding the big picture?