no. not only is there no guarantee, there is in fact a promise that you are mistaken to count on any order between the two.
also, in an extreme case where func1 and func2 did not produce output (like a channel) consumed by someone who waits for them...in which case neither of them may run at all! On Tue, Feb 21, 2017 at 12:41 AM, Marwan abdel moneim <mrwnm...@gmail.com> wrote: > 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> >> 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. > -- Michael T. Jones michael.jo...@gmail.com -- 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.
