Doesn't the fact that Go and Java use User space thread mean that you can't really take advantage of multiple core?

We've been talking about threads in my operating system class a lot lately and one 开发者_如何学运维question has come to my mind.

Since Go, (and Java) uses User-space thread instead of kernel threads, doesn't that mean that you can't effectively take advantages of multiple cores since the OS only allocates CPU time to the process and not the threads themselves?

This seems to confirm the fact that you can't

Wikipedia also seems to think so

What makes you think Go uses User-space threads?

It doesn't. It uses OS-threads and can take advantage of multiple cores.

You might be puzzled by the fact that by default Go only uses 1 thread to run your program. If you start two goroutines they run in one thread. But if one goroutine blocks for I/O Go creates a second thread and continues to run the other goroutine on the new thread.

If you really want to unlock the full multi-core power just use the GOMAXPROCS() function.

runtime.GOMAXPROCS(4); //somewhere in main

Now your program would use 4 OS-threads (instead of 1) and would be able to fully use a e.g. 4 core system.

Most recent versions of Java to use OS threads, although there is not necessarily a one-to-one mapping with Java threads. Java clearly does work quite nicely across many hardware threads.

I presume that by "user-space threads" you mean (for example) Go's goroutines.

It is true that using goroutines for concurrency is less efficient than designing (by hand and by scientific calculations) a special-purpose algorithm for assigning work units to OS threads.

However: Every Go program is situated in an environment and is designed to solve a particular problem. A new goroutine can be started for each request that the environment is making to the Go program. If the environment is making concurrent requests to the Go program, a Go program using goroutines might be able to run faster than a serial program even if the Go program is using just 1 OS thread. The reason why goroutines might be able to process requests with greater speed (even when using just 1 OS thread) is that the Go program will automatically switch from goroutine A to goroutine B when the part of environment which is associated with A is momentarily unable to respond.

But yes, it is true that using goroutines and automatically assigning them to multiple OS threads is less efficient than designing (by hand and by scientific calculations) a special-purpose algorithm for assigning work units to OS threads.