On Sun, Feb 19, 2017 at 9:41 AM Marwan abdel moneim <mrwnm...@gmail.com> 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.
