The green threading M:N model requires a larger language runtime to manage threads. As such, the Rust standard library only provides an implementation of 1:1 threading.
From effective java: The best way to write a robust, responsive, portable program is to ensure that the average number of runnable threads is not significantly greater than the number of processors. This leaves the thread scheduler with little choice: it simply runs the runnable threads till they’re no longer runnable.
这个对scheduler的不信任不能说完全不合理。
【 在 sui (黑圈圈) 的大作中提到: 】 : 请教，这个特性是语言层面的还是底层实现的问题？其他语言有没有可能逐渐也实现这 : 个呢？
Every languages worth mentioning today have these.
【 在 chebyshev (......) 的大作中提到: 】 : wdong 2015年说过这个关键的地方。 : 这几年下来，基本情况没update。 : (1) : Golang 可以自动调度N任务在M kernel线程across P multi-cores。 : 这个不管做得好坏。难度是非常大的。 : linux是1:1. : (2) Rust : https://doc.rust-lang.org/1.24.1/book/second-edition/ch16-01- : threads.html : The green threading M:N model requires a larger language runtime to manage : threads. As such, the Rust standard library only provides an implementation : ...................
another example我贴过了。rust文档如下： The green threading M:N model requires a larger language runtime to manage threads. As such, the Rust standard library only provides an implementation of 1:1 threading.
" A thread pool does not let me have M stacks at a time. It only lets me have N - the same number of OS threads. You cannot take a task running on a threadpool thread and suspend it, can you? You can a goroutine or Erlang process.
That's why it's thread pools aren't M:N - they only have N stacks. They're N:N (so 1:1), with an extra queue of M jobs, but they aren't running until there's space in the N OS threads.
Goroutines do not have the same problem as I've described, because they can run M stacks at a time - M jobs can make progress towards meeting at the barrier, and then cooperatively (so we don't need preemption here - they're doing it cooperatively so not being preemptible isn't relevant here) deschedule themselves while waiting at the barrier, allowing another of the goroutines to be scheduled and to make progress.
Source: I wrote a PhD on concurrency and parallelism models and programming language implementation, and I work at Oracle on Java virtual machines. "
【 在 hci (海螺子) 的大作中提到: 】 : No. : Every languages worth mentioning today have these. : implementation
Go 这些年没啥好吹的才来吹 green thread / co-routine，因为之前它的 GC 太烂了。
【 在 chebyshev (......) 的大作中提到: 】 : wdong 2015年说过这个关键的地方。 : 这几年下来，基本情况没update。 : (1) : Golang 可以自动调度N任务在M kernel线程across P multi-cores。 : 这个不管做得好坏。难度是非常大的。 : linux是1:1. : (2) Rust : https://doc.rust-lang.org/1.24.1/book/second-edition/ch16-01- : threads.html : The green threading M:N model requires a larger language runtime to manage : threads. As such, the Rust standard library only provides an implementation : ...................
Why do you quote a stupid person who has not worked in any real application?
I said in this board a few weeks ago, "Don't listen to these stupid recommendation about how many threads should be in your thread pool."
Listen to me: use thousands of threads in your pool.
The reason is simple, most modern programming is doing IO, so you block on IO everywhere: network requests, database request, file system, EVERYWHERE.
You need those threads in your async thread pool, otherwise, you will quickly run out of threads because all of them are waiting on something.
I know, you are not "supposed" to block in the "async" code, but NO, you WILL be blocking in your async code, because all the low level stuff are blocking.
Don't read stupid comments on the Internet, instead, build things and try things yourself.
【 在 guvest (我爱你老婆Anna) 的大作中提到: 】 : Java is 1:1, from reedit by a Phd in concurrency: : " : A thread pool does not let me have M stacks at a time. It only lets me have : N - the same number of OS threads. You cannot take a task running on a : threadpool thread and suspend it, can you? You can a goroutine or Erlang : process. : That's why it's thread pools aren't M:N - they only have N stacks. They're N : :N (so 1:1), with an extra queue of M jobs, but they aren't running until : there's space in the N OS threads. : Goroutines do not have the same problem as I've described, because they can : ...................
wdong 2015年说过这个关键的地方。
这几年下来，基本情况没update。
(1)
Golang 可以自动调度N任务在M kernel线程across P multi-cores。
这个不管做得好坏。难度是非常大的。
linux是1:1.
(2) Rust : https://doc.rust-lang.org/1.24.1/book/second-edition/ch16-01-
threads.html
The green threading M:N model requires a larger language runtime to manage
threads. As such, the Rust standard library only provides an implementation of 1:1 threading.
(3)
2012 Golang scheduler design spechttps://docs.google.com/document/d/1TTj4T2JO42uD5ID9e89oa0sLKhJYD0Y_
kqxDv3I3XMw/edit
请教，这个特性是语言层面的还是底层实现的问题？其他语言有没有可能逐渐也实现这个呢？
理论上我觉得这应该是OS干的事。实现这个很难。
不管是谁.
一来spec难写。不知道该满足哪一类需求。
第二，就算spec写了。不管啥资源，task assignment时不时的就会冒出来NP hard啊。那么只能用一些简单但是强壮的基本方法。写好以后，再回过头改问题的定义，甚至要求程序员follow 所谓的goog practice。
From effective java:
The best way to write a robust, responsive, portable program is to ensure
that the average number of runnable threads is not significantly greater
than the number of processors. This leaves the thread scheduler with little choice: it simply runs the runnable threads till they’re no longer runnable.
这个对scheduler的不信任不能说完全不合理。
【 在 sui (黑圈圈) 的大作中提到: 】
: 请教，这个特性是语言层面的还是底层实现的问题？其他语言有没有可能逐渐也实现这
: 个呢？
No.
Every languages worth mentioning today have these.
【 在 chebyshev (......) 的大作中提到: 】
: wdong 2015年说过这个关键的地方。
: 这几年下来，基本情况没update。
: (1)
: Golang 可以自动调度N任务在M kernel线程across P multi-cores。
: 这个不管做得好坏。难度是非常大的。
: linux是1:1.
: (2) Rust : https://doc.rust-lang.org/1.24.1/book/second-edition/ch16-01-
: threads.html
: The green threading M:N model requires a larger language runtime to manage
: threads. As such, the Rust standard library only provides an
implementation
: ...................
(1)
Java by default自带是1：1的(自己写的不算。)。这源自于当初Solaris，linux没搞
定。
java跟着OS走。我查了一下，多年前这方面的论文还颇有一些。
以前java社区应该是有过1：N的。我记不确切了。
但是三层调度，java社区也好，别的社区也好，都是我没有见过的。
another example我贴过了。rust文档如下：
The green threading M:N model requires a larger language runtime to manage
threads. As such, the Rust standard library only provides an implementation
of 1:1 threading.
(2)
Golang这个三层调度应用效果如何先不讲。
实事求是的讲，没有失败还是很厉害的。这条路可以说已经开出来了。
再过5年，精通golang性能调优的专家就会流行的。
就跟今日懂jvm的人类似。
【 在 hci (海螺子) 的大作中提到: 】
: No.
: Every languages worth mentioning today have these.
: implementation
Java is 1:1, from reedit by a Phd in concurrency:
"
A thread pool does not let me have M stacks at a time. It only lets me have N - the same number of OS threads. You cannot take a task running on a
threadpool thread and suspend it, can you? You can a goroutine or Erlang
process.
That's why it's thread pools aren't M:N - they only have N stacks. They're N:N (so 1:1), with an extra queue of M jobs, but they aren't running until
there's space in the N OS threads.
Goroutines do not have the same problem as I've described, because they can run M stacks at a time - M jobs can make progress towards meeting at the
barrier, and then cooperatively (so we don't need preemption here - they're doing it cooperatively so not being preemptible isn't relevant here)
deschedule themselves while waiting at the barrier, allowing another of the goroutines to be scheduled and to make progress.
Source: I wrote a PhD on concurrency and parallelism models and programming language implementation, and I work at Oracle on Java virtual machines.
"
【 在 hci (海螺子) 的大作中提到: 】
: No.
: Every languages worth mentioning today have these.
: implementation
Haskell GHC 从 04 年就支持 N:M 调度了。
Go 这些年没啥好吹的才来吹 green thread / co-routine，因为之前它的 GC 太烂了。
【 在 chebyshev (......) 的大作中提到: 】
: wdong 2015年说过这个关键的地方。
: 这几年下来，基本情况没update。
: (1)
: Golang 可以自动调度N任务在M kernel线程across P multi-cores。
: 这个不管做得好坏。难度是非常大的。
: linux是1:1.
: (2) Rust : https://doc.rust-lang.org/1.24.1/book/second-edition/ch16-01-
: threads.html
: The green threading M:N model requires a larger language runtime to manage
: threads. As such, the Rust standard library only provides an
implementation
: ...................
No.
Why do you quote a stupid person who has not worked in any real application?
I said in this board a few weeks ago, "Don't listen to these stupid
recommendation about how many threads should be in your thread pool."
Listen to me: use thousands of threads in your pool.
The reason is simple, most modern programming is doing IO, so you block on
IO everywhere: network requests, database request, file system, EVERYWHERE.
You need those threads in your async thread pool, otherwise, you will
quickly run out of threads because all of them are waiting on something.
I know, you are not "supposed" to block in the "async" code, but NO, you
WILL be blocking in your async code, because all the low level stuff are
blocking.
Don't read stupid comments on the Internet, instead, build things and try
things yourself.
【 在 guvest (我爱你老婆Anna) 的大作中提到: 】
: Java is 1:1, from reedit by a Phd in concurrency:
: "
: A thread pool does not let me have M stacks at a time. It only lets me
have
: N - the same number of OS threads. You cannot take a task running on a
: threadpool thread and suspend it, can you? You can a goroutine or Erlang
: process.
: That's why it's thread pools aren't M:N - they only have N stacks. They're N
: :N (so 1:1), with an extra queue of M jobs, but they aren't running until : there's space in the N OS threads.
: Goroutines do not have the same problem as I've described, because they
can
: ...................