Linux线程模型比Windows效率高?该怎么解决

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).

我们知道,Linux下没有任何关于线程的系统调用,内核对线程一无所知,用于实现多线程的,是几个线程包(LinuxThreads,pthread等等),而Windows下,内核把线程当作调度实体,线程调度在内核内完成。而其他Unix系统,比如FreeBSD,Minix3同样是选择了在用户层面实现多线程,而一些系统比如Solaris则使用混合方案。
那么,是否可以初步断定:Linux下的多线程效率比Windows高?
但是Linux下的多线程有明显缺点:
1.每个线程的pid不一样,Linux用clone函数来实现多线程,实际上是创建的轻量进程,所以pid不一样。
2.fork的影响,一个线程执行fork,竟然只会复制一个线程。
3.信号的影响。
所以我得出结论:Linux的用户级线程虽然效率较高,但并不完全符合线程模型。
这个结论是否正确了?希望大家能广泛讨论
------解决方案--------------------
linux的线程(至少pthread)不是用户线程
------解决方案--------------------
你既然已经看过《操作系统设计与实现》了,那就应该知道无论是在内核空间还是用户空间支持线程,都有各

自的优缺点,所以肯定还会有别的更优的解决方案了~~

linux下的线程,确实不符合理论上的线程模型。在linux下,线程是和进程共用一个结构体,即task_struct来

刻画的,只是创建的是线程的时候,会将一些资源属性设置为共享的,这样看起来就像是一个进程内的多个线

程可以共享某部分数据似的

而POSIX的pthread,则完全是用户空间的线程。而linux同时支持内核线程和用户空间的线程。

线程这东西,虽然理论上相似,但是几乎各个系统实现的都不一样,主流的几个分别是Solaris,linux,mach

和windows,相关的讲解在<UNIX Internals>这本书中介绍的非常详细~~

PS:轻量级进程(LWP)这个做的最好的是solaris,在《Solaris内核结构》(第二版)中,对solaris上的进程线

程支持也讲得非常清楚~~建议楼主还是多看看书,然后直接读读内核代码,别盲从别人,这样才能真正有所得
------解决方案--------------------
[Quote=引用:]

你既然已经看过《操作系统设计与实现》了,那就应该知道无论是在内核空间还是用户空间支持线程,都有各

自的优缺点,所以肯定还会有别的更优的解决方案了~~

linux下的线程,确实不符合理论上的线程模型。在linux下,线程是和进程共用一个结构体,即task_struct来

刻画的,只是创建的是线程的时候,会将一些资源属性设置为共享的,这样看起来就像是一个进程内的多个线

程可以……]

过儿,弄错了吧。

Linux 的 POSIX Thread (PThread)是内核线程,用户接口库的实现名称是 NPTL (Native Posix Threading Library)。这个库所管理的线程,每个对应于内核中一个单独调度的 task_struct;进程对应于一个 tg(task group?忘记了)。每个 task_struct 分别有 pid 和 tgid,用于标识线程号和进程号(这里名字应该是从 2.4 带来的时候引起的遗留问题)

真正的用户态线程是 Pth,也是一个 POSIX Thread 标准的实现,但是并不常用。
------解决方案--------------------
从软件规模和线程的使用就可以看出来,Windows下的独立程序普遍规模较大,一个进程里几百个线程非常常见,如果是轻量进程,开销还得了么