Thanks, That was very useful, I did slip on the globals definition. And I also kind of overlook init()s running before main(). Although I have to check what happens exactly when a go statement is kicked off on an init() body, will it wait for main()?
Also yes, the bottom line for race free code is *no write should happen on a goroutine while at least another goroutine can be accessing that value* *concurrently* (to read or write it). But starting to think how a tool would check it we know that: - If there are no go statement there is only 1 thread, then we are safe. - Variables can only be reachable from more than one goroutine if they: A) Were passed (by reference) as argument or via channel. B) Are global, and thus reachable from anywhere (if public) or their whole package (if private) How could a variable be reachable from several goroutines otherwise? El lunes, 2 de enero de 2017, 0:48:28 (UTC+1), Michael Jones escribió: > > Josvazg, Your notion of "globals safe" should allow init() functions as > safe writers. They are always invoked serially. > > On Sun, Jan 1, 2017 at 7:29 AM <chrisst...@gmail.com <javascript:>> wrote: > >> >> On Sunday, January 1, 2017 at 4:43:32 AM UTC-7, 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. >>> >> >> >>> Otherwise: >>> >> >>> - >>> >>> A program is globals safe if any of this is true: >>> - >>> >>> There are no global variables. >>> - >>> >>> Globals are read only. >>> - >>> >>> Globals are only ever modified by the same goroutine. >>> - >>> >>> Globals are only accessed under the same mutex. >>> >>> >> Hi, creating a list of cases that are either safe or unsafe would be >> infinite and likely error prone as seen above. For example *"**Globals >> are only ever modified by the same goroutine."* is not accurate because >> a read during a write is a data race. I would check out the Go Memory >> Model[1] to get a precise understanding, while sticking to the simple well >> defined rule[2] that: >> >> "A data race occurs when two or more goroutines access the same variable >> concurrently (an access means a READ or a WRITE) and at least one of the >> accesses is a write." >> >> [1] https://golang.org/ref/mem >> [2] https://golang.org/doc/articles/race_detector.html >> >> >> >> >> >> >> >> >> >> -- >> >> >> 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...@googlegroups.com <javascript:>. >> >> >> For more options, visit https://groups.google.com/d/optout. >> >> >> -- 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.
