9 ms·
> Thanks to goroutines and channels Go programmers can take a different approach. Instead of using locks to control access to a shared resource, they can simply
by andreareina 9y ago
> Thanks to goroutines and channels Go programmers can take a different approach. Instead of using locks to control access to a shared resource, they can simply use channels to pass around its pointer. Then only a goroutine that holds the pointer can use it and make modifications to the shared structure.
How does this prevent data races if more than one goroutine holds a pointer to the shard structure and they're running concurrently?
- kasey_junk 9y agoIt doesn't.
- viiralvx 9y agoYeah, I think you'd still want mutex to handle that. I always use a mutex when dealing with goroutines and maps, for example.
- mpd 9y agoAs others have said, the scenario you describe wouldn't prevent data races at all. Under the channels model, you wouldn't want more than one goroutine to be accessing the shared structure. One routine would hold the reference to the resource, and other routines talk with the first routine via channels (i.e. share memory by communicating).
- innocentoldguy 9y agoIt doesn't. I think goroutines make concurrency easier that it is in, say, Java, but Go still passes around state and that is where a lot of the issues with concurrency arise. Concurrency is much easier to deal with in functional languages, where data is transformed via chains of functions, rather than stored in state.
- alphaalpha101 9y agoThe difference is that in Go, it is unidiomatic to share mutable state across threads, while in C/C++/Java it's not.
- camus2 9y agoIt does not.