What are the disadvantages of the M: N thread model (e.g. goroutines)?

Question

M: N threading is a model that maps M user threads to N kernel threads. This allows you to create a large number of (M) user threads due to their low mass, which still allows (N-way) parallelism.

This seems win-win for me, so why are so few languages ​​/ implementations using this threading model? The only examples I know about are Go "goroutines" and Erlang processes.

What are the disadvantages of M: N thread? Why don't other languages ​​use this threading model, which at first glance seems so promising?

Answer 1

This is partly because "this is what everyone else is doing." Although M: N threads existed before Go, all major languages ​​(C, C ++, Perl, Java, C #, Python, Ruby, PHP) used threads, and many of them (Python, Ruby) did this poorly. Go is the first popular language that shows that M: N threads can work well.

This is partly because threads are a natural primitive of the OS.

Implementing M: N streaming makes interacting with OS code / C libraries harder and slightly slower. When invoking the code, C / OS Go should switch from the small goroutine stack to the regular operating system stack.

Many other popular languages ​​(Python, Ruby) rely more on the ability to invoke C code than Go, so it is more important for them to optimize for this.

A good M: N stream of interaction with OS / C code is not impossible (Go does it decently), but it is easier to do if you do what the OS does.