On Sun, 12 Mar 2017 23:39:59 -0700 (PDT) Albert Tedja <nicho.te...@gmail.com> wrote:
> I know map itself isn't threadsafe, but I am just wondering how > threadsafe it is if you can be absolutely sure that each goroutine > accesses a different key in the map. > Say, goroutine 1 accesses mymap["1"] > and goroutine 2 accesses mymap["2"] and so on. Contrary to a struct type, values of which are just pretty "static" pieces of memory, where the compiler known an offset (in bytes) of each field relative to the value's starting address, a value of a map type contains a pointer to an intricate *dynamic* thing, where each insertion of a new value might lead to drastic changes like moving of unrelated values already stored in that map in memory. Because of this, the only thing guaranteed to work concurrently with Go maps is reading them. So if your goroutites only read a map value, then it does not matter which values they read. If they write to a map (that is, insert into it or delete from it), you must synchronize the accesses to that no write even happens concurrently with either another write or a read. On the other hand, consider that if you store in the map pointers to actual values which are themselves not stored in a map, then, after reading such a pointer from a map, you're free to deal with the value it points to concurrently with map modification. That's because in this scenario, the only values stored by the map are pointers, and hence insertion to the map and deletions from it might move those pointers in memory but not the values they point to. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
