What (if any) map operations are guaranteed when accessed concurrently?

<p>So I&#39;m aware of both <a href="https://blog.golang.org/go-maps-in-action" rel="nofollow">this</a> and <a href="https://golang.org/doc/faq#atomic_maps" rel="nofollow">that</a> saying maps are not safe for concurrent use.</p> <p>My question is,</p> <blockquote> <p>What (if any) map operations are guaranteed when accessed concurrently?</p> </blockquote> <p>For example:</p> <ul> <li>Concurrent reads without concurrent writes?</li> <li>Concurrent read/writes of keys already existing in the map of values which are primitive types (int/float/pointer/etc)?</li> <li>Concurrent reads of keys with concurrent writes to other keys not being read?</li> </ul> <p>It&#39;d be nice to know if it&#39;s possible to safely use a sub-set of the features of maps concurrently. Thanks!</p> <p>EDIT: Thanks folks! <a href="/u/dgryski" rel="nofollow">/u/dgryski</a> pointed out that Go 1.6 will panic if detects concurrent read/write on a map, so I think that answers the question (unless there&#39;s some nuance they missed).</p> <hr/>**评论：**<br/><br/>dgryski: <pre><p>Only reads. Go 1.6 will panic if it detects any map write executing concurrent to any map read.</p></pre>dlsniper: <pre><p>You can safely do concurrent reads from the map as long as you don&#39;t write to it. If you want to write to it then you have to grt exclusive access to the whole map (no other goroutine should perform any operation on it at the same time) Use a rwmutex to flag access to it. </p></pre>Akkifokkusu: <pre><p>Just to clarify what might be the premise of one of your questions:</p> <blockquote> <p>Concurrent read/writes of keys already existing in the map of values which are primitive types (int/float/pointer/etc)?</p> </blockquote> <p>&#34;Primitive types&#34; have the same concurrency guarantee as maps. Concurrent reads are safe. Writes concurrent with reads or other writes are not.</p></pre>earthboundkid: <pre><p>Adding to that: if you need atomic updates to an int and don&#39;t want to use channels or mutexes for some reason, there&#39;s a sync/atomic package in the standard library. </p></pre>joushou: <pre><p>Remember that sync/atomic is low-level, and can break in unexpected ways if you don&#39;t know what you&#39;re doing. Atomic access to an int64 on some 32bit platforms has certain alignment requirements, for example.</p></pre>BenjaminZarzycki: <pre><blockquote> <p>Writes concurrent with reads or other writes are not [safe]</p> </blockquote> <p>How are concurrent read/writes on an int32 unsafe? isn&#39;t it guaranteed to be read as either the value before the write or the value after the write?</p></pre>Akkifokkusu: <pre><p>Is not knowing which value will be read considered safe? Consider incrementing a counter. That involves a two-step process, a read followed by a write. But without a mutex or the functions in <code>sync/atomic</code>, there&#39;s no guarantee that nothing else will modify the variable between the two steps.</p> <p>You might be interested in <a href="https://golang.org/ref/mem" rel="nofollow">https://golang.org/ref/mem</a>, especially the &#34;Advice&#34; and &#34;Incorrect synchronization&#34; sections.</p></pre>DualRearWheels: <pre><p>Just to add that RWMutex is made for these situations <a href="https://golang.org/pkg/sync/" rel="nofollow">https://golang.org/pkg/sync/</a></p></pre>