On Sunday, 1 January 2017 06:43:32 UTC-5, josvazg wrote: > I am trying to come up with a detailed definition of what a thread safe Go > program is (and is not). One that a (go) tool could check by analyzing the > code for me. >
You've set yourself an impossible task. A function is thread-safe (or concurrency-safe) if calling it concurrently from two or more goroutines does not cause it to behave incorrectly. The problem is that in software, even in the absence of concurrency, no-one can really define what "correctly" means precisely enough for a tool to verify it. There are static and dynamic tools for detecting concurrency problems, but they make very narrow and precise definitions of "correct". For example, Go's race detector is a dynamic analysis that reports any data races (concurrent accesses to variables where at least one of the accesses is a write) it finds during execution. As another example, C++'s Annotalysis is a static checker for a non-standard type system (requiring explicit annotations) that can catch misuse of some common locking patterns. But even if your code passes these two checks, it may still have data races or other kinds of races, locking problems, deadlocks, or a variety of other concurrency problems, plus all the usual bugs of a single-threaded program. -- 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. For more options, visit https://groups.google.com/d/optout.
