Am i correct to assume from previous messages that if I use MAX_PROCS=1 and don't use channels, my functions will run from start to end in the order they've been piled up using the `go` keyword?
This could yield interesting properties, because this means that even using channels, maybe we could write concurrent code and still have a chance to have predictable and reproducible execution in testing environment. On Friday, November 25, 2016 at 10:51:41 PM UTC+1, Dave Cheney wrote: > > > > On Saturday, 26 November 2016 08:00:24 UTC+11, Roger Alsing wrote: >> >> So it works very similar to normal OS thread context switching, but more >> explicit? >> > > Yes, goroutine switching occurs a known points; effectively where the > goroutine is blocked from proceeding; sending and receiving on channels (if > they are full/empty respectively), trying to acquire a locked mutex, and > performing IO. These operations happen frequently in a program that > interacts with others so things more or less work out. > > >> The code will push all local state to the go routine stack, pop the state >> for the next go routine and change the stack pointer? >> > > The cute thing is the Go function call convention is caller save, so when > a goroutine enters the scheduler there is no state to be saved, it's > already saved on the stack by the normal function call convention. As Ian > said above the scheduler just finds the SP and PC for a new goroutine and > swaps them for the current one. The new goroutine awakes at the bottom of > the scheduler, and returns to its original control flow. > > >> >> And this is cheaper than context switching as threads have their own 1 or >> 4 mb stack allocated while go routines have a linked list for its stack >> (afaik?) ? >> > > Goroutines used to have a linked list of stack segments, we dropped that > in Go 1.3 (might have been 1.2, i'd have to check), now stack segments grow > and shrink with a cheap check in the preamble of the function; if there > isn't enough stack to perform the function (this is known precisely at > compile time), then the function traps into a slow path that doubles the > stack allocation by copying the whole stack to a new area, then restarts > the function. Stack shrinking is handled via the GC cycle when a goroutine > has a large amount of unused stack. > > >> is that the major difference? >> > > I think so, it makes goroutines cheap to create; only a few kb of initial > stack, cheap to use; no trip through kernel space to save a lot of state, > and trash TLB's and caches, and cheap to have many of them; in operation > hundreds of thousands of goroutines in a busy server are the norm. This is > also pretty much the case against threads. > > Here is a presentation I gave at OSCON last year about all these things, > https://dave.cheney.net/2015/08/08/performance-without-the-event-loop > > >> >> >> Den fredag 25 november 2016 kl. 17:34:24 UTC+1 skrev Ian Lance Taylor: >>> >>> On Fri, Nov 25, 2016 at 2:18 AM, <roger...@gmail.com> wrote: >>> > I have seen a lot of confusion on how go routines actually work >>> internally. >>> > Will the function execution ontop of the go routine be rewritten to a >>> statemachine with continuations in the same way as the C# async await does? >>> >>> I do not know how C# async await works. That said, goroutines are not >>> rewritten to state machines. >>> >>> >>> > If I have only 1 OS thread and 1000 go routines, obviously there must >>> be some sort of "magic" that makes it possible to multiplex these ontop of >>> that thread. >>> > How do the go routines store state so that they can continue from the >>> last execution point when they resume execution? >>> >>> A goroutine is basically a small stack. All the goroutine state is >>> saved on the stack. To switch to a different goroutine, the goroutine >>> scheduler changes the stack pointer. On the new goroutine, it looks >>> like the function call into the scheduler simply returns, and the >>> goroutine continues running. >>> >>> This is a standard programming technique known as a "coroutine". For >>> Go we used the name "goroutine" because 1) it is cute; 2) goroutines >>> have functionality not available in most coroutine libraries, such as >>> multiplexing across many OS threads and automatic use of epoll for >>> network connections. >>> >>> >>> > Is it safe to say that Go gives you the exact same support as the C# >>> (and others) async await while still writing code that looks sequential? >>> >>> I don't know C#. goroutines let you write code that looks sequential >>> because it actually is sequential. >>> >>> Ian >>> >> -- 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.
