理论上我觉得这应该是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的不信任不能说完全不合理。
No. Every languages worth mentioning today have these.
implementation
【在 c*******v 的大作中提到】 : 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的人类似。
【在 h*i 的大作中提到】 : 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. "
【在 h*i 的大作中提到】 : No. : Every languages worth mentioning today have these. : : implementation
B*a
13 楼
有一次在老墨店看到有卖丝瓜瓤子的,洗澡用
【在 D***e 的大作中提到】 : 就是老丝瓜的瓤,洗碗用
a*e
14 楼
Haskell GHC 从 04 年就支持 N:M 调度了。 Go 这些年没啥好吹的才来吹 green thread / co-routine,因为之前它的 GC 太烂了。
implementation
【在 c*******v 的大作中提到】 : 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
y*8
15 楼
老美店也有。做成手套的形状,很漂亮的,就是价格不菲了。
【在 B*******a 的大作中提到】 : 有一次在老墨店看到有卖丝瓜瓤子的,洗澡用
h*i
16 楼
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.
have N can
【在 g****t 的大作中提到】 : 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