title: Data race with std::unordered_map, despite locking insertions with mutex
body: <p>I have a C++11 program that does some computations and uses a <code>std::unordered_map</code> to cache results of those computations. The program uses multiple threads and they use a shared <code>unordered_map</code> to store and share the results of the computations. </p>
  
  <p>Based on my reading of <code>unordered_map</code> and STL container specs, as well as <a href="https://stackoverflow.com/questions/9685486/unordered-map-thread-safety">unordered_map thread safety</a>, it seems that an <code>unordered_map</code>, shared by multiple threads, can handle one thread writing at a time, but many readers at a time. </p>
  
  <p>Therefore, I'm using a <code>std::mutex</code> to wrap my <code>insert()</code> calls to the map, so that at most only one thread is inserting at a time. </p>
  
  <p>However, my <code>find()</code> calls do not have a mutex as, from my reading, it seems that many threads should be able to read at once. However, I'm occasionally getting data races (as detected by TSAN), manifesting themselves in a SEGV. The data race clearly points to the <code>insert()</code> and <code>find()</code> calls that I mentioned above. </p>
  
  <p>When I wrap the <code>find()</code> calls in a mutex, the problem goes away. However, I don't want to serialize the concurrent reads, as I'm trying to make this program as fast as possible. (FYI: I'm running using gcc 5.4.)</p>
  
  <p>Why is this happening? Is my understanding of the concurrency guarantees of <code>std::unordered_map</code> incorrect?</p>