Ruby的伪线程

粗略查了一下, 好像 HP-UX 11i (B.11.22), Solaris 2.6 起都有了 Scheduler Activation 机制, 其他的OS不太清楚.

另外以前就知道Solaris有Light Weight Procss, 好像也是2.6开始有的, 这个似乎比 Scheduler Activation 更进一步.

问题有两个，一个是用户级线程和核心级线程如何映射的问题，一个是线程本身的控制管理问题。

如果用户级线程跟核心级线程是1：1映射的，那就意味着用户级线程这个概念是多余的，我们就可以简单的叫做线程，或者叫做1：1线程模型，它其实就是核心级线程。

如果用户级线程跟核心级线程是M：N映射的，这表明M个用户级线程映射到N个核心级线程之上，这时候，用户级线程这个概念才是必须的，才有其存在的必要，有人提出来，用户级线程只能使用一个CPU的核，这个其实是限制了N必须为1才导致的一个局限，从逻辑上讲，用户级线程没有限制自己使用CPU核的能力，虽然现在M：N的映射中N常常是1，但不表示N必须是1。

线程这个概念其实也有点演进，作为一个执行和调度的线索，其创建、销毁和调度（切换）机制是由谁实施的决定了其本身的性能和表达能力。最明显的是一个执行线索是否可以被剥夺把线程模型区分成两大类。一般来说，用户级线程是指这些机制（创建，销毁，切换和调度）是由用户级的库来实现的，而核心级显然是有OS Kernel实现这些机制的。现代的线程机制，已经不再是这么简单的一刀切的方式来实施了，而是由核心和用户共同协作来完成线程的控制管理的。由于核心可以提供全系统的事件和资源使用情况的全图，而应用一般更清楚各个线程之间的逻辑依赖关系，所以理论上也是他们合作会产生更高的效能。Activation Scheduler就是基于这个想法而出现的。简单的说：AS的想法是，线程的创建由应用提出申请，核心创建（给出一个虚拟CPU），而销毁确由应用自己决定，调度依赖于核心和用户的协作，用户可以自主调度（注意，这儿显然是不可剥夺模式的），核心在发现阻塞是可以通知应用，这时候，应用（用户级线程库）应该切换线程，这样，核心和用户协作，实现了更高性能的线程模型。

个人认为，在碰到用户级线程和内核线程这些概念时，一定要弄清楚线程的层次结构，弄清楚在谈论这些层次结构时所影射的参照系。参照系选择的是VM呢，还是OS，自己心中要有数。

可以看看“Solaris的线程模型”，直观明白，地址是：http://java.sun.com/docs/hotspot/threads/threads.html；

当然也可以看看“ Thread的层次结构”，地址是：http://zhangyu8374.iteye.com/blog/86297