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. 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. But then, goroutines may communicate in a circle, the smallest would be two sending to each other and awaiting answer from each other at the "same" time. A system would easily freeze from this point and out. This would cause deadlock, which is pathological. Using deadlock free patterns may solve that problem from the beginning, provided such a pattern is used correctly. Finally(?), one goroutine could be busy by itself, or by communicating with others, so that it is not able to read vital messages from other goroutines, ever. This would be a livelock. I think go comes with a tool [1] that would help for some of these types of problems. I have not tested it myself, since I use another, embedded concurrent language. But I do read these mail lists every time they come, so I try to learn what this community is up to. There would be ways whereby one could model concurrent programs as well. Lots of modelling languages exist. Myself I have to some extent used CSPm (with the FDR tool), FSP (with the LTSA tool) and Promela (with the Spin tool). [1] https://golang.org/doc/articles/race_detector.html torsdag 26. november 2020 kl. 03:55:06 UTC+1 skrev Ian Lance Taylor: > On Wed, Nov 25, 2020 at 6:13 PM Alexey Dvoretskiy > <advor...@emeraldcloudlab.com> wrote: > > > > How would you cal "thread-safety" in Go? Go doesn't have threads so the > term "thread-safety" sounds bit off. > > The standard library says things like "Multiple goroutines may invoke > methods on a Conn simultaneously" (from > https://golang.org/pkg/net/#Conn). > > Terms like "thread safety" can come with various caveats and > restrictions, so it's usually best to avoid just saying "thread safe" > in general purpose documentations. Better to try to say more > precisely what is and what is not supported. > > Ian > -- 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/97d39db9-fd05-4f57-a3a5-50ff2eb8f298n%40googlegroups.com.
