I learnt that, the reason we have context(`P`) introduced in Goruntime, is that we can hand them off(it's LRQ of goroutines) to other OS thread(say `M0`), if the running OS thread(`M1`) needs to block for some reason.
[image: Untitled.png] ------------------------------ Above, we see a thread(`M1`) giving up its context so that another thread(`M0`) can run it. The Go scheduler makes sure there are enough threads to run all contexts(`P1`, `P2`, `P3` etc..). ---------------- Above model is `M:N` [threading model](https://cs.stackexchange.com/questions/1074/what-is-the-purpose-of-mn-hybrid-threading), where each OS thread(`M1`) running on CPU core(`C`) assigned a context(`P`) having `K` goroutines in it's LRQ. vis-a-vis `1:1` threading model, where each core(`C`) has one OS thread(`M`). `pthread_create()`. Comparing above two threading models, context switching of go-routines(in `M:N` threading model) is much faster than context-switching of OS threads(in `1:1` threading model) -------------------------- To understand the purpose of context(`P`), what is the advantage of handing off context(`P1`) to other thread(say `M2`) running on core(`C2`)? Is the advantage about efficiency in re-using cache lines(L1/L2) on core `C2`, for the related set of goroutines sitting in LRQ of context(`P1`)? -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/b014cfa5-1b03-4ac0-87c0-8ec292965c9d%40googlegroups.com.
