[andreareina]

> 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?

[mpd]

As 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).

[viiralvx]

Yeah, I think you'd still want mutex to handle that. I always use a mutex when dealing with goroutines and maps, for example.

[innocentoldguy]

It 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]

The difference is that in Go, it is unidiomatic to share mutable state across threads, while in C/C++/Java it's not.

[kasey_junk]

It doesn't.

[camus2]

It does not.