Go scheduler - What is the purpose of Context(P)?

[overex...@gmail.com]

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.

------------------------------

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`)?

[Ian Lance Taylor]

What do you mean when you write  context(`P`)?  By that do you simply mean what the runtime package calls a P?  A P is a logical processor; see the long comment at the top of runtime/proc.go.

Ian

[overex...@gmail.com]

Yes you are right, P is a logical processor holding LRQ of go-routines

[Ian Lance Taylor]

On Thu, May 14, 2020 at 2:53 PM <overex...@gmail.com> wrote:

Yes you are right, P is a logical processor holding LRQ of go-routines

The purpose of a P is to limit the amount of total concurrency running Go code.  By default we set the number of P's to the number of CPU cores on the system (including hyperthreading).  The user can control it by setting the GOMAXPROCS environment variable, and the program can control it by calling runtime.GOMAXPROCS.

M's, on the other hand, which are operating system threads, are started as needed, so the user and program have no control over them.  G's, which are goroutines, are started by the program but there is no way to limit the total number of goroutines.

So using P's is how the Go runtime tries to keep the program running efficiently without thrashing.

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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/10edb2a0-4770-436d-8c68-812a4d88b8e7%40googlegroups.com.