On Friday, 27 November 2020 at 10:32:11 UTC oyvin...@teigfam.net wrote: > Thread safety, concurrency safety, goroutines safety. The same stuff to > me. > > It's important that concurrent goroutines don't interfere with each other > in such a way that internal state is compromised by other goroutines. > Typically through access to internal data, through pointers. >
Not just that, but also: - any global variables. Even reading an 'int' while some other goroutine is updating it is unsafe; it may give undefined behavior. - concurrent read and write accesses to the same map or slice can cause the program to panic. Note that map and slice values contain hidden pointers inside them. So if two goroutines have the same map or slice value, they are aliasing to the same underlying data. These can trip up people used to (say) Python, where such accesses are atomic - primarily because of Python's Global Interpreter Lock. (There is sync.Map <https://golang.org/pkg/sync/#Map> which is concurrency-safe, but if you need this, there's probably a better solution in your architecture) > If only go channels are used to communicate between goroutines, than that > case is closed. That's one of the reasons they exist - also in other > similar languages, with that aspect often based on CSP. > Here's a video explaining how channels can replace various concurrency primitives: it's worth getting your head around. https://www.youtube.com/watch?v=5zXAHh5tJqQ -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/57144fb7-712b-4bde-9ed4-f98c06c27241n%40googlegroups.com.
