This is the third day of my participation in the August More text Challenge. For details, see:August is more challenging
Common threading model
- Single threaded server programming model: Redis, Node., JavaScript
- Multithreaded server programming model: Multiple threads are concurrent, each performing different tasks in parallel
- Master-slave multithreaded mode: two thread pools
Distinguished Name Description
Light Weight Process (LWP) : A lightweight process is what we usually call a thread. Since each lightweight process is supported by a kernel thread, a lightweight process can only exist if the kernel thread is supported first
Three threading models
- One-to-one model
- Many-to-one model
- Many-to-many model
One-to-one model
The user thread corresponds to the system thread one by one. When the user thread performs system calls such as LO operation, the overhead of switching back and forth operation is relatively large
Many-to-one model
Multiple user threads correspond to a kernel thread. When a user thread corresponding to a kernel thread is blocked and suspended, the other user threads are blocked and cannot execute.
Many-to-many model
The many-to-many model can make full use of the multi-core CPU to improve performance
The Go thread model belongs to the multi-pair multi-thread model
The Go-thread model contains three concepts: kernel thread (M), Goroutine (G),G context (P);
GMP model
The GMP model is specific to GoalNG.
- G is a goroutine, a user-mode thread based on a coroutine
- M is machine, which is directly associated with an OS kernel thread that executes G.
- P is the processor, which usually stores the context (function pointer, stack address, and address boundary) of the current Goroutine. P does some scheduling for the goroutine queues managed by it
GMP scheduling
When an OS thread blocks while executing M1 and a G1, the scheduler tells M1 to discard P, wait for G1 to return, and then another M2 receives P to execute the remaining Goroutine queue (G2, G3…). This is the great thing about the Golang scheduler, which ensures that there are enough threads to run all the remaining Goroutines.
When G1 is finished, M1 will return to P to complete, and if not, it will be thrown into the global RunQueue and then put into the thread pool itself or go to sleep. The idle context P periodically checks the goroutine on the global Runqueue and executes it.
Another scenario is when some P1s are too busy and other P2s are busy, and some G is taken from other context P2s for execution.
Read the first reference link below for more details. It’s very well written.
The characteristics of
- User space avoids the cost of switching between kernel mode and user mode
- Scheduling can be done by the language and framework layers
- The smaller stack space allows a large number of instances to be created
conclusion
———— Go language runtime, through the core elements G, M, P and their own scheduler, to achieve their own concurrent thread model. The scheduler implements scheduling tasks outside the operating system kernel in the two-level threading model by scheduling G, M and P. The whole scheduling process will be to trigger the core steps in a variety of time “scheduling” whole round, round the whole scheduling is one of the most critical part in the “full search can run G”, it ensures the efficient of M (in other words, full use of the computer’s physical resources), also involved in the whole round scheduling M enable to stop. Finally, don’t forget that there is a system monitoring task that is the same as the Go program lifecycle to do some ancillary work.
reference
Brief analysis of Golang thread model and scheduler
Golang CSP concurrency model
Golang threading model