title: How safe are Golang maps for concurrent Read/Write operations?
body: <p>According to the Go blog,</p>
  
  <blockquote>
    <p>Maps are not safe for concurrent use: it's not defined what happens when you read and write to them simultaneously. If you need to read from and write to a map from concurrently executing goroutines, the accesses must be mediated by some kind of synchronization mechanism.
    (source: <a href="https://blog.golang.org/go-maps-in-action" rel="noreferrer">https://blog.golang.org/go-maps-in-action</a>)</p>
  </blockquote>
  
  <p>Can anyone elaborate on this? Concurrent read operations seem permissible across routines, but concurrent read/write operations may generate a race condition if one attempts to read from and write to the same key.</p>
  
  <p>Can this last risk be reduced in some cases? For example: </p>
  
  <ul>
  <li>Function A generates k and sets m[k]=0. This is the only time A writes to map m. k is known to not be in m.</li>
  <li>A passes k to function B running concurrently</li>
  <li>A then reads m[k]. If m[k]==0, it waits, continuing only when m[k]!=0</li>
  <li>B looks for k in the map. If it finds it, B sets m[k] to some positive integer. If it doesn't it waits until k is in m.</li>
  </ul>
  
  <p>This isn't code (obviously) but I think it shows the outlines of a case where even if A and B both try to access m there won't be a race condition, or if there is it won't matter because of the additional constraints.</p>