even if i wrote > go func1
go func2 is there any guarantee that func1 will run first? even just the first instruction? On Sunday, February 19, 2017 at 11:25:34 PM UTC+2, Jesper Louis Andersen wrote: > > On Sun, Feb 19, 2017 at 9:41 AM Marwan abdel moneim <mrwn...@gmail.com > <javascript:>> wrote: > >> i wanted to do it without a Mutex >> but there still something not clear to me, but i don't know what it is >> and i don't understand what "trigger" synchronization means >> >> > Modern CPUs achieve much of their speed by running instructions > out-of-order and completing them out of order as well. The CPU operates on > multiple instructions at the same time, and 50 instructions is not unheard > of. They also write data back to caches and memory in the background while > doing other things. This means that your memory is "eventually consistent" > in the sense that eventually data will be written back. But there is no > guarantee when that is, and "never" is a valid option in some extreme cases. > > In a system with multiple physical cores, different cores may see wildly > different data in memory because of the above optimizations. As a result, > any unsynchronized operation is undefined behavior: it may read anything or > never store data correctly. > > Go, and most other languages, provide some kind of guaranteed memory model > which explains exactly when the system makes sure that data written back to > memory is consistent, so other processor cores (and thus goroutines) can > safely read the data. In Go, the memory model concerns itself about > Mutex'es and channel's specifically. > > The Go compiler is then responsible for taking a particular processor > architecture, x86-64, AArch64, ..., and map its specific internal data > coherency model onto the Go memory model, so you get the same guarantees, > irrespective of what architecture your program is running on. > > This also holds true for a C program, and in particular for C programs: > The C compilers are often very aggressive in their optimizations and as a > result they have a penchant for optimizing away operations if they can. > Without proper synchronization, this may wreak havoc on your programs. > > It must also be said that many programs look correct, but are actually > faulty w.r.t to synchronization safety. It is common, for instance, that > the problems only start showing once you start loading your program with > more work. That is, the program tests correct, but fails in a load > benchmark or production, whichever happens first. > > -- 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.
