11

I am confused by goroutine, user thread, and kernel thread concepts

  1. From effective go introduce goroutine, so what does os threads means which mentioned by the paper? Does it mean user thread or kernel thread?

  2. From go-scheduler paper, I learn about M G P, and why the numbers of P is equal to the numbers of CPU? If all the cpus serve for the go program, but other program in the os system have no cpu thread to execute?

  3. How many kernel thread generated by the os system?

Jonathan Hall
  • 75,165
  • 16
  • 143
  • 189
Jim Green
  • 1,088
  • 3
  • 15
  • 40
  • 2
    I think you should take measures to gain more generic knowledge about how a contemporary commodity OS shares CPU time and other resources between the processes running on it. You can start [here](https://en.wikipedia.org/wiki/Preemption_(computing)) but a good introductory-level book should also help. – kostix Feb 06 '18 at 09:44
  • Related: [How do goroutines work? (or: goroutines and OS threads relation)](https://stackoverflow.com/q/24599645/1256452) – torek Dec 18 '19 at 22:35
  • 1
    As an appendix to @kostix's comment. [Operating System Concepts](https://www.amazon.com/Operating-System-Concepts-Abraham-Silberschatz/dp/1119800366/ref=sr_1_1?keywords=operating+system+concepts&qid=1686797558&sr=8-1) is a great book to start with. – Paul Jun 15 '23 at 02:55

1 Answers1

17

Let's include the picture from the go-scheduler page you linked to.

enter image description here

And establish the terminology:

  • M: OS thread, can also be called a kernel thread
  • P: processor, or scheduling context
  • G: Goroutine

goroutines are what we are most familiar with in Go, and could be considered user threads. A more technical name for those is Green Threads.

P is used to perform the mapping from many goroutines to many OS threads. There is one per OS thread, and the number is determined by the value of GOMAXPROCS (by default, the number of CPUs as reported by your system).

So, to answer your questions in order:

  • OS thread means kernel thread
  • GOMAXPROCS defaults to the number of cores, but you can change that. Just because you can run on all cores does not mean you're not leaving CPU time for other processes. Concurrency usually involves a lot of waiting for IO. Even if you're going crazy hashing things, the kernel scheduler will boot you off to run other things.
  • there are as many OS threads as needed. Looking at ps -eL, my system currently has 1434, some of them actual kernel jobs, some for my go program.

You can find a really good explanation of OS vs Green threads in this answer

Marc
  • 19,394
  • 6
  • 47
  • 51
  • 1
    I'd also recommend to read [this post](https://rakyll.org/scheduler/) by one of the Go developers. – kostix Feb 06 '18 at 09:42
  • Thank you very much for your answer.You solve a lot of my questions. What happened if `GOMAXPROCS ` > cpu numbers? Will it cause os schedule from user-level thread ->kernel thread -> user-level thread ? – Jim Green Feb 06 '18 at 10:03
  • 1
    No, the OS only schedules kernel threads, it doesn't know about user threads. It's also not rare for the actual number of OS threads used by Go to exceed GOMAXPROCS. See https://dave.cheney.net/tag/gomaxprocs. It sounds like you need to read up on OS basics. Maybe start with https://en.wikipedia.org/wiki/Scheduling_(computing) – Marc Feb 06 '18 at 10:20
  • I have read your reference . So what will happened if GOMAXPROCS > cpu numbers? – Jim Green Feb 06 '18 at 10:45
  • 1
    Again: nothing bad. Go will make use of more kernel threads than there are cpus, and the kernel will keep scheduling those appropriately. The reason GOMAXPROCS is set to the number of CPUs is that the fanning out is done with goroutines, so there's little point in having more scheduling contexts than there are CPUs. Also: there are often more when they're waiting, or executing cgo. – Marc Feb 06 '18 at 10:46