Linux线程模型比Windows效率高？
最近在看操作系统（Minix3）代码，才注意到这个以前不关注的问题，不过似乎这个问题在CSDN论坛经常讨论，我在这里再次发贴，希望不会引起口水。
Dr.Tanenbaum的书中说：“在有些操作系统中，系统感知不到线程的存在。换言之，线程完全在用户空间进行管理。在另外一些系统中，操作系统知道每个进程中存在多个线程，所以当一个线程阻塞时，操作系统会继续选择下一个运行的线程，它可能来自同一个进程，或者其他进程。为了进行调度，内核必须有一张线程表，其中列出了系统的所有线程”
接下一段的意思说：用户级线程包的切换比内核级切换快得多，但有明显的缺点。
上面这段话的英文原文：In some systems, the operating system is not aware of the threads. In other words, they are managed entirely in user space. When a thread is about to block, for example, it chooses and starts its successor before stopping. Several userlevel threads packages are in common use, including the POSIX P-threads and Mach C-threads packages.[Page 67]In other systems, the operating system is aware of the existence of multiple threads per process, so when a thread blocks, the operating system chooses the next one to run, either from the same process or a different one. To do scheduling, the kernel must have a thread table that lists all the threads in the system, analogous to the process table.Although these two alternatives may seem equivalent, they differ considerably in performance. Switching threads is much faster when thread management is done in user space than when a system call is needed. This fact argues strongly for doing thread management in user space. On the other hand, when threads are managed entirely in user space and one thread blocks (e.g., waiting for I/O or a page fault to be handled), the kernel blocks the entire process, since it is not even aware that other threads exist. This fact as well as others argue for doing thread management in the kernel (Boehm, 2005). As a consequence, both systems are in use, and various hybrid schemes have been proposed as well (Anderson et al., 1992).
