<p>the documentation on this package is incredibly minimal and I'm having a hard time understanding how to make basic examples.</p>
<p><a href="https://godoc.org/golang.org/x/sync/syncmap" rel="nofollow">https://godoc.org/golang.org/x/sync/syncmap</a></p>
<p>func main() {<br/>
m := new(syncmap.Map)<br/>
m.Store("adf", 123)<br/>
fmt.Println(m)</p>
<p>}</p>
<p>above prints out</p>
<p>&{{0 0} {{} {map[] true}} map[adf:0xc42000c028] 0}</p>
<p>if someone could help me with some super basic examples of each method in this package, that would help me a lot</p>
<hr/>**评论：**<br/><br/>Sythe2o0: <pre><p><code>Delete</code> is equivalent to <code>delete</code>, <code>Store</code> is equivalent to <code>map[key] = value</code>, <code>Load</code> is equivalent to <code>x = map[key]</code>, and <code>LoadOrStore</code> is equivalent to </p>
<pre><code>if _, ok := map[key]; !ok {
map[key] = value
return value, false
}
return map[key], true
</code></pre>
<p><code>Range</code> is is a little more complicated but has sufficient documentation. </p></pre>ar1819: <pre><p>This is because syncmap is not meant to be general purpose concurrent map. If you don't know what you really doing - don't use it. Pick mutex and standard map instead - it will be more efficient and less space costly. </p></pre>dchapes: <pre><blockquote>
<p>syncmap is not meant to be general purpose concurrent map</p>
</blockquote>
<p>To be clearer on this point, read the <a href="https://tip.golang.org/pkg/sync#Map" rel="nofollow"><code>sync.Map</code> documentation</a>:</p>
<blockquote>
<p>It is optimized for use in concurrent loops with keys that are stable over time, and either few steady-state stores, or stores localized to one goroutine per key.</p>
<p>For use cases that do not share these attributes, it will likely have comparable or worse performance and worse type safety than an ordinary map paired with a read-write mutex.</p>
</blockquote></pre>peepdippn: <pre><p>mutexs do not not play nice when used with layers of concurrency, it slows it down a good bit from what I read but I could be wrong.</p>
<p>I have a massive program that does thousands and sometimes 10k+ iterations whose results are maps. Using workers that have workers, I've managed to cut down what initially took 15 minutes down to 6.5 minutes.</p>
<p>Now, I have to make sure that the maps get written back correctly and from what I read, writing to maps isn't concurrent safe in go. A bit more digging and I found this package although the documentation isn't exactly robust.</p></pre>ar1819: <pre><p>If your keys do not overlap constantly you will surely have the same lock contention as before. In your scenario I suppose you can either try to shard map so you can probably decrease lock contention if keys do not overlap this often. Or - look at the lock free map implementation, tho I never used one in my experience with Go. </p></pre>hipone: <pre><p>You can't print a map like that, you'd need to take a lock in order to inspect all values. You could either read sync.Map's godoc and figure it out on your own, or whine on reddit and get working solution.</p>
<p>Since you've chosen the latter, here you go (MIT):</p>
<pre><code>func debug(m sync.Map) {
s := make(map[interface{}]interface{})
m.Range(func(k, v interface{}) bool {
s[k] = v
return true
})
fmt.Println(s)
}
</code></pre>
<p>While we're at it, you could add support for sync.Map to pretty-printing libraries like kr/pretty and so on.</p></pre>bkeroack: <pre><p>sync.Map is pretty useless. They should have waited for some kind of generics solution before introducing it into the standard library. </p>
<p>Just use regular maps and wrap in a mutex later on if needed. </p></pre>peepdippn: <pre><p>according to this </p>
<p><a href="https://github.com/golang/go/issues/17973" rel="nofollow">https://github.com/golang/go/issues/17973</a></p>
<p>mutex scales poorly. I should of mentioned that I have workers that have workers due to how much information that needs to process. Per job right now on a single day, I have to process at minimum 6000 individual things, with the upper parts being probably around 15k, so I wrote a program that has uses layers of concurrency. What once took 15 minutes now takes 6.5 but now the trick is to make writing these map values back safely and maps aren't concurrent safe from what I read about go. I stumbled onto this package but it has very minimal information.</p>
<p>we need performance and since we're tapping out resources just to process these jobs, using mutex's will not produce the results we're looking for.</p></pre>TheMerovius: <pre><p>Please watch <a href="https://www.youtube.com/watch?v=C1EtfDnsdDs" rel="nofollow">this</a> to see, whether or not sync.Map is appropriate for your use-case. It almost certainly isn't.</p></pre>jerf: <pre><p>"Mutex scales poorly" is a bit of a generalization. RWMutex isn't sync.Mutex in general, and that program is also a pathological case where everything is at maximum contention; I suspect that in a common case where the computation you are doing is much larger than the cost of a lock you won't see that problem. You should benchmark before assuming performance, and you should <em>certainly</em> benchmark something like that before bending the architecture of your solution to avoid a "fact" that may not even be true for you, when something easier may have been available to you.</p>
<p>I still don't know what you're doing so I can't be sure, but I suspect-without-proof a case of doing communication by sharing memory, instead of sharing by communication. You may want to consider restructuring your task entirely to work in a different way. It's also valid to share "pre-written" maps that are then read-only for all users without locks.</p>
<p>You may be able to structure your code into one goroutine that reads the incoming request and breaks it into pieces, which pushes the pieces down a channel to a pool of goroutine workers, who then have a channel where they push the results (<code>chan struct { Key Keytype, Value Valuetype}</code>) to a goroutine that puts them in the final map. Or perhaps something else, who knows. Is it really necessary for everything to be in one shared data structure that every goroutine truly needs intimate read and write access at every moment to? Generally not because even you have safely locked the map itself for reading and writing the fact that the values are still nondeterministic relative to what a goroutine expects means the algorithm doesn't really need that. Usually if they are sharing, it's something like "incrementing" which can be done by having each small goroutine prepare its results and send it to a single "reducing" goroutine to be merged into the final answer.</p>
<p>This isn't even about "Go" per se either; Go happens to do some things that make this easy, but these are <em>general</em> principles about concurrent programming. There are no languages or runtimes where you can have tons of threads running around and mutating a shared structure without paying lots of performance penalty; the hardware itself fundamentally doesn't like that.</p></pre>bkeroack: <pre><p>Have you benchmarked? 15k is not that much. </p>
<p>Also it's an anti pattern to share a heavily used data structure among large numbers of goroutines. Share memory by communicating. </p></pre>Should_have_listened: <pre><blockquote>
<p>should of </p>
</blockquote>
<p>Did you mean should have? </p>
<hr/>
<p>This is a bot account.</p></pre>dchapes: <pre><p>See the <a href="https://youtu.be/C1EtfDnsdDs?t=1m37s" rel="nofollow">video posted by /u/TheMerovius</a> that directly answers why it's in the standard library, "so that [they] can use it in the standard library" (I suppose they could have put it into an <code>/internal/</code> package).</p></pre>_youtubot_: <pre><p>Video linked by <a href="/u/dchapes" rel="nofollow">/u/dchapes</a>:</p>
<table><thead>
<tr>
<th align="center">Title</th>
<th align="center">Channel</th>
<th align="center">Published</th>
<th align="center">Duration</th>
<th align="center">Likes</th>
<th align="center">Total Views</th>
</tr>
</thead><tbody>
<tr>
<td align="center"><a href="https://youtu.be/C1EtfDnsdDs?t=1m37s" rel="nofollow">GopherCon 2017 - Lightning Talk: Bryan C Mills - An overview of sync.Map</a></td>
<td align="center">Gopher Academy</td>
<td align="center">2017-07-24</td>
<td align="center">0:08:10</td>
<td align="center">19+ (100%)</td>
<td align="center">697</td>
</tr>
</tbody></table>
<hr/>
<p><a href="https://np.reddit.com/r/youtubot/wiki/index" rel="nofollow"><sup>Info</sup></a> <sup>|</sup> <a href="https://np.reddit.com/message/compose/?to=_youtubot_&subject=delete%20comment&message=dm0iz0g%0A%0AReason%3A%20%2A%2Aplease+help+us+improve%2A%2A" rel="nofollow"><sup>/u/dchapes</sup> <sup>can</sup> <sup>delete</sup></a> <sup>|</sup> <sup>v1.1.3b</sup></p></pre>hipone: <pre><p>Pardon me, but your opinion is useless, not sync.Map.</p></pre>
