5 ms·
Hi, author of the post here. Which example doesn't work? I just pasted the communicate by sharing memory example into the go playground: https://play.golang.org
by iamjfu 7y ago
Hi, author of the post here. Which example doesn't work? I just pasted the communicate by sharing memory example into the go playground: https://play.golang.org/p/bWtyGTC-EsC https://play.golang.org/p/bWtyGTC-EsC and it gives the same length every time. Am I missing something or are you referring to a different example?
> More on-topic, channels have their own tradeoffs. I often reach for WaitGroups and mutexes instead of channels, because things can get complicated fast when you're routing data around with channels
You're absolutely right. I certainly didn't intend to give a blanket recommendation. It's more of a, "If you're sharing memory, might it become clearer if you share memory by communicating?" I was worried that the simplistic examples would not properly represent the cases I was thinking of. I think that's a communication error on me.
- carbocation 7y agoThe Go playground is designed to be deterministic, right? Not sure that’s a useful test. On mobile so I can’t compile right now or else I’d take a look.
- elithrar 7y agoCorrect. Results are cached for the same program “ID”.
- modernerd 7y agoI think it's only consistent in play.golang.org because results are cached: https://blog.golang.org/playground https://blog.golang.org/playground. If I run it locally it's not consistent: go run lock/main.go [3 0 1 2 5 4 6 9 7 8] 10⏎ go run lock/main.go [1 5 6 7 8 0] 6⏎ go run lock/main.go [0 3 1 2 4 5 6 7 8] 9⏎ Here's a version that does work for me: https://play.golang.org/p/b6bRb9pgIGZ https://play.golang.org/p/b6bRb9pgIGZ The issue is that appending to slices concurrently is not safe, so you have to use a lock around the append or similar.
- iamjfu 7y agoTIL. That's a huge flaw. Thanks so much for your response!
- modernerd 7y agoWelcome! It's the same for other data structures, by the way (not just slices) — maps are not safe for concurrent writes either. (The rationale seems to be that users of the data types can choose whether to make them safe for concurrent use or not depending on the use case.) I found this helpful: https://youtu.be/29LLRKIL_TI?t=1340 https://youtu.be/29LLRKIL_TI?t=1340
- masklinn 7y ago> The rationale seems to be that users of the data types can choose whether to make them safe for concurrent use or not depending on the use case. Also that for most uses a concurrent map is way overkill, and a thread-safe one is both costly and basically useless (hence the Java folks not keeping the thread-safety when migrating from Hashtable to HashMap). On the other hand they're kinda shit given how awful non-builtin data structures are in Go, and how easy it is to "leak" maps between goroutines.
- vips7L 7y agoHashtable used a giant mutex when locking.. it was just slow. Especially when compared to ConcurrentHashMap.
- irq-1 7y agoThey added sync.Map > Map is like a Go map[interface{}]interface{} but is safe for concurrent use by multiple goroutines without additional locking or coordination. Loads, stores, and deletes run in amortized constant time. https://golang.org/pkg/sync/#Map https://golang.org/pkg/sync/#Map
- empath75 7y agoIf you try to run a naive version of this in rust, the compiler won't even run it. https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=59d2eb657b3cbd5da5914beb6aa98f08 https://play.rust-lang.org/?version=stable&mode=debug&editio... I'm a beginner at rust, but this is the version I came up with that compiles and works: https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=83ec90561271b46abc8df451991fd4f0 https://play.rust-lang.org/?version=stable&mode=debug&editio...
- TomNomNom 7y agoRan the example on my machine and can confirm it's broken. Be careful relying on the results of the Go playground; it has a bunch of differences and probably has GOMAXPROCS set to 1, which most other systems will not. You need a sync.Mutex or similar protecting your call to append :)