如果程序具有更多线程，我的程序会获得更多的cpu时间吗？

Question

If currently kernel is scheduling 60 threads, they belong to 3 processes:

A: 10 threads

B: 20 threads

C: 30 threads

And they are all doing computing (no disk IO)

Will C gets more stuff done than B, and B gets more stuff done than A?

It does not seem very fair to me. If I am a irresponsible programmer, I can just spawn more threads to eat more CPU resource.

How this relate to golang: In go, typically the go scheduler has a thread pool of #of-CPU-cores threads. Why does this make sense if a process with more threads gets more stuff done?

Answer 1

It does not seem very fair to me. If I am a irresponsible programmer, I can just spawn more threads to eat more CPU resource.

you can also allocate your entire free memory, cause OS-failure and hijack the network card. you can do sorts of things but then who will want to consume your softwares?

How this relate to golang: In go, typically the go scheduler has a thread pool of #of-CPU-cores threads. Why does this make sense if a process with more threads gets more stuff done?

Golang goroutines are basically a threadpool. each goroutine is a thread-pool work item. many things can make your thread-pool thread block, like using synchronous IO, waiting on a (non-spin-lock) lock and manually sleeping or yielding. in these cases, which are very common, having more threads than CPU's usually increase the performance of your application.
Do note that not all IO is a disk IO. writing to your console is an IO operation, but it isn't really a "Disk IO".

another thing is that context switching may not consume a large portion of your CPU, and having more threads may not make your tasks-throughput degrade. so in this case having more threads means that your parallelism is higher, and yet you don't loose performance. this is somewhat common situation. context switching between threads these days is very cheap. having a bit more threads than your cores may not necessary kill your performance or degrade it in some way.