|
锁定老帖子 主题：Ruby的伪线程
该帖已经被评为良好帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2006-10-29
robbin 写道 rails的ActiveRecord不是线程安全的，如果ruby真提供了native thread的VM，那么rails的代码就得彻底大改动了，这可不是我所希望看到的。
对于运行web应用来说，其实现在ruby1.8.4用FastCGI方式运行挺好的了。也许ruby不应该遵循JavaVM曾经走过的那条路。 记得原来偶然看到JDK代码有一段,说是修正一个bug,保证Primitive类型的原子操作的,比如一个线程在取一个 long 字段的值的时候, 不至于取了高32位以后切换到另一个线程, 正好修改了它(低32位变掉了), 再切换回来继续取低32位, 这样整个long值就是一个拼起来的数,丧失100%正确性. 看了这篇文章, 感觉Ruby一定要实现伪线程, 也许就是为了可以防止类似的并发访问陷阱. 而如果用native thread的话, 想保证100%正确性势必要在每个native thread中对每个Ruby的元操作(像取变量值, 存变量值这种)进行同步, 这个开销足以让多native thread的Ruby解释器性能降至比伪线程的解释器性能还低. 而在伪线程的方案中解释器只要选择在元操作的边界切换伪线程就可以简单的解决这个问题. 所以选择伪线程应该是解释器的局限, 如果通过VM方式执行, 就有可能在VM级别以可接受的成本实现元操作的保障. 好像主流的Ruby应用还是用解释器执行的吧? 解释执行的Ruby应该是没可能走JVM的路. |
| 返回顶楼 | |
|
发表时间：2006-10-31
伪线程这个名字有点……嗯……不是很好听。
这个叫做用户级线程，其优势是非常明显的，最主要的是性能奇高。当然，很多人会觉得这是瞎说。但这是真的。用户级线程也有缺陷，就是阻塞的全局性。这个缺陷导致用户级线程应用场合有限。现在，有两个模型把核心级线程和用户级线程影射起来，一个是1：1，一个是M：N。现在非常流行的是1：1方式。这也是Linux的NPTL采用的方式。 |
| 返回顶楼 | |
|
发表时间：2006-10-31
fixopen 写道 伪线程这个名字有点……嗯……不是很好听。
这个叫做用户级线程，其优势是非常明显的，最主要的是性能奇高。当然，很多人会觉得这是瞎说。但这是真的。用户级线程也有缺陷，就是阻塞的全局性。这个缺陷导致用户级线程应用场合有限。现在，有两个模型把核心级线程和用户级线程影射起来，一个是1：1，一个是M：N。现在非常流行的是1：1方式。这也是Linux的NPTL采用的方式。 能否更加详细点谈谈? |
| 返回顶楼 | |
|
发表时间：2006-10-31
fixopen 写道 伪线程这个名字有点……嗯……不是很好听。
这个叫做用户级线程，其优势是非常明显的，最主要的是性能奇高。当然，很多人会觉得这是瞎说。但这是真的。用户级线程也有缺陷，就是阻塞的全局性。这个缺陷导致用户级线程应用场合有限。现在，有两个模型把核心级线程和用户级线程影射起来，一个是1：1，一个是M：N。现在非常流行的是1：1方式。这也是Linux的NPTL采用的方式。 在单CPU核心*硬线程的体系上说 "性能奇高" 是可以成立的, 但是如果用上像 SPARC T1 这种多至 8核心*4线程单元 = 32并发硬线程的系统上, 所谓的用户级线程还是把它当一个最原始的CPU在用. 即便是单核心的 Pentium 4, 也有支持HyperThread技术的两道硬线程机构. 伪线程的程序除了以多进程执行以外是没法有效利用现代的处理器资源的. |
| 返回顶楼 | |
|
发表时间：2006-10-31
fixopen 写道 伪线程这个名字有点……嗯……不是很好听。
这个叫做用户级线程，其优势是非常明显的，最主要的是性能奇高。当然，很多人会觉得这是瞎说。但这是真的。用户级线程也有缺陷，就是阻塞的全局性。这个缺陷导致用户级线程应用场合有限。现在，有两个模型把核心级线程和用户级线程影射起来，一个是1：1，一个是M：N。现在非常流行的是1：1方式。这也是Linux的NPTL采用的方式。 看来你概念不清。NPTL和ruby线程是两码事。就是在Linux Kernel2.6上面跑(support NPTL)，一个ruby进程里面就算有n个线程，操作系统照样只能用一个进程(一个线程)去hold，根本不可能出现1:1，除非ruby像JVM那样实现native thread，不过那还是非常遥远的事情。 |
| 返回顶楼 | |
|
发表时间：2006-10-31
robbin 写道 rails的ActiveRecord不是线程安全的，如果ruby真提供了native thread的VM，那么rails的代码就得彻底大改动了，这可不是我所希望看到的。
对于运行web应用来说，其实现在ruby1.8.4用FastCGI方式运行挺好的了。也许ruby不应该遵循JavaVM曾经走过的那条路。 JRuby是native thread，它可以跑ActiveRecord。不知道他们是怎么实现的，但由此可以推断，如果Ruby将来支持native thread，ActiveRecord不会是个大问题。 |
| 返回顶楼 | |
|
发表时间：2006-11-01
aardvark 写道 robbin 写道 rails的ActiveRecord不是线程安全的，如果ruby真提供了native thread的VM，那么rails的代码就得彻底大改动了，这可不是我所希望看到的。
对于运行web应用来说，其实现在ruby1.8.4用FastCGI方式运行挺好的了。也许ruby不应该遵循JavaVM曾经走过的那条路。 JRuby是native thread，它可以跑ActiveRecord。不知道他们是怎么实现的，但由此可以推断，如果Ruby将来支持native thread，ActiveRecord不会是个大问题。 不清楚jruby想用多线程方式还是多进程方式跑rails。但我很怀疑是用多线程方式跑的，Rails本身不是线程安全的，据zed shaw说meta programming也有很多线程安全问题。 |
| 返回顶楼 | |
|
发表时间：2006-11-01
fixopen 写道 伪线程这个名字有点……嗯……不是很好听。
这个叫做用户级线程，其优势是非常明显的，最主要的是性能奇高。当然，很多人会觉得这是瞎说。但这是真的。用户级线程也有缺陷，就是阻塞的全局性。这个缺陷导致用户级线程应用场合有限。现在，有两个模型把核心级线程和用户级线程影射起来，一个是1：1，一个是M：N。现在非常流行的是1：1方式。这也是Linux的NPTL采用的方式。 伪线程和用户级线程都是标准的英文术语，指的是同一个东西。要是Ruby有Erlang(微进程)或Haskell那样的M:N方式就好了，不过这是更加’非常遥远的事‘了 
|
| 返回顶楼 | |
|
发表时间：2006-11-01
引用 看来你概念不清。NPTL和ruby线程是两码事。就是在Linux Kernel2.6上面跑(support NPTL)，一个ruby进程里面就算有n个线程，操作系统照样只能用一个进程(一个线程)去hold，根本不可能出现1:1，除非ruby像JVM那样实现native thread，不过那还是非常遥远的事情。 虽然你是老大，但是麻烦你看清楚我说的话好不好？我什么时候说过ruby的用户级线程就是Linux的NPTL了？我说的是NPTL是1：1，而用户级线程一般叫做M：N。这里面最好的模型（我认为的）是Activation Scheduler，但是现在只有NetBSD？支持。 另外我想说的是：我已经强调了用户级线程的阻塞全局性了。所以提到多个CPU核心的人没有打中靶子。 |
| 返回顶楼 | |
|
发表时间：2006-11-01
fixopen 写道 引用 看来你概念不清。NPTL和ruby线程是两码事。就是在Linux Kernel2.6上面跑(support NPTL)，一个ruby进程里面就算有n个线程，操作系统照样只能用一个进程(一个线程)去hold，根本不可能出现1:1，除非ruby像JVM那样实现native thread，不过那还是非常遥远的事情。 虽然你是老大，但是麻烦你看清楚我说的话好不好？我什么时候说过ruby的用户级线程就是Linux的NPTL了？我说的是NPTL是1：1，而用户级线程一般叫做M：N。这里面最好的模型（我认为的）是Activation Scheduler，但是现在只有NetBSD？支持。 另外我想说的是：我已经强调了用户级线程的阻塞全局性了。所以提到多个CPU核心的人没有打中靶子。 不光是阻塞的时候吧, 不阻塞的时候也只能利用起一个CPU核心呢, 其余的都在闲置. |
| 返回顶楼 | |
