Linux2.6内核实现的是NPTL

NPTL是一个1×1的线程模型，即一个线程对于一个操作系统的调度进程，优点是非常简单。而其他一些操作系统比如Solaris则是MxN的，M对应创建的线程数，N对应操作系统可以运行的实体。(N<M)，优点是线程切换快，但实现稍复杂

转

Linux2.6内核实现的是NPTL线程模型，依然是用进程来模拟线程，但新引入了线程组(进程组)的概念，使得实现效率更好。

在2.4内核中，不存在线程组的概念，当运行一个多线程得程序时，使用ps命令，可以看到有许多个进程，在ps命令看来，线程基本上是等同于进程，在信号处理中，情况也是如此，只有指定进程号的线程，可以接收到信号。在2.6内核中引入了线程组的概念，在2.6内核中，如果使用ps命令看，一个多线程的进程，只会显示一个进程，在给线程组中的任何一个线程发送信号的时候，整个线程组中的进程都能收到信号。
在内核task_struct中相关字段如下（位于include/linux/sched.h）：

代码: 全选

937   struct task_struct 
{
       
 ...
993    
 pid_t pid;
994 
    pid_t tgid;
         ...
1013     struct task_struct *group_leader;   /* threadgroup leader
*/
       
 ...
1017   
 struct list_head thread_group;
         ...
1198  };

pid，从字面上是process id，但其实是thread id。
tgid，从字面上，应该是thread group
id，也就是真正的process
id。
这一点，可以从系统调用getpid和gettid中看出来（位于kernel/timer.c）。

代码: 全选

954   asmlinkage long
sys_getpid(void)
955   {
956      return current->tgid;
957   }
1100  asmlinkage long
sys_gettid(void)
1101  {
1102     return current->pid;
1103  }

group_leader字段，指向线程组中的第一个线程，创建第一个线程的时候，group_leader指向自己，创建其后的线程时，指向第一个线程的task_struct结构；
thread_group，当前进程所有线程的队列，对于group_leader，这是个队列头，对于其后的进程而言，通过这个字段，挂入队列中，可以通过此队列，遍历所有线程。
线程组中各个线程的关系，是在do_fork中设定的，具体的代码在copy_process中（位于kernel/fork.c）：代码: 全选

959 
 copy_process()
960   {
         ...
1112     p->tgid = p->pid;
1113     if (clone_flags &
CLONE_THREAD)
1114        p->tgid = current->tgid;
         ...
1181     p->group_leader =
p;
1182   
 INIT_LIST_HEAD(&p->thread_group);
         ...
1234     if (clone_flags &
CLONE_THREAD) {
1235        p->group_leader =
current->group_leader;
1236        list_add_tail_rcu(&p->thread_group,
&p->group_leader->thread_group);
      ...
1252     }

1254     if (likely(p->pid))
{
          
 ...
1259      
 if (thread_group_leader(p)) {
             
 ...
1266      
    list_add_tail_rcu(&p->tasks,
&init_task.tasks);
               ...
1268        }
            ...
1271     }
         ...
1320  }

1113-1114行说明在创建线程时，从父进程获取tgid，表明他们在同一个线程组中；1181-1182则对group_leader和thread_group初始化，对于第一个线程，则group_leader就是它自己；1234-1236行，将新创建的线程的group_leader设置成为父进程得group_leader，无论父进程是不是线程组中的第一个线程，它的group_leader都是指向第一个线程的task_struct，同时通过thread_group字段，挂入到第一个线程的thread_group队列中；1266行表明只有线程组中的第一个线程，才会通过tasks字段，挂入到init_task队列中。
在引入线程组概念后，退出部分也引入了一个新的系统调用exit_group（位于kernel/exit.c）

1055  NORET_TYPE
void
1056  do_group_exit(int
exit_code)
1057  {
1058     BUG_ON(exit_code
& 0x80); /* core dumps don‘t get here
*/
1059
1060     if
(current->signal->flags & SIGNAL_GROUP_EXIT)
1061   
    exit_code = current->signal->group_exit_code;
1062   
 else if (!thread_group_empty(current)) {
1063        struct
signal_struct *const sig = current->signal;
1064      
 struct sighand_struct *const sighand =
current->sighand;
1065      
 spin_lock_irq(&sighand->siglock);
1066        if
(sig->flags & SIGNAL_GROUP_EXIT)
1067           /*
Another thread got here before we took the lock.  */
1068      
    exit_code = sig->group_exit_code;
1069        else
{
1070           sig->group_exit_code =
exit_code;
1071         
 zap_other_threads(current);
1072        }
1073 
      spin_unlock_irq(&sighand->siglock);
1074 
 }
1075
1076   
 do_exit(exit_code);
1077     /* NOTREACHED
*/
1078  }

在1060行中，current->signal其实是线程组中所有线程共享的，对于调用exit_group的那个线程，如果是一个多线程的进程，就会进入1062-1074这部分代码，如果是单线程，则直接进入do_exit退出进程。这部分代码的主要操作在zap_other_threads中（位于kernel/signal.c）

void zap_other_threads(struct
task_struct *p)
982 
 {
983      struct task_struct *t;
984 
 
985      p->signal->flags =
SIGNAL_GROUP_EXIT;
986      p->signal->group_stop_count =
0;
987
988      if
(thread_group_empty(p))
989       
 return;
990
991      for (t = next_thread(p); t
!= p; t = next_thread(t)) {
992         /*
993 
        * Don‘t bother with already dead threads
994         
*/
995         if (t->exit_state)
996       
    continue;
997
998         /* SIGKILL will be
handled before any pending SIGSTOP */
999       
 sigaddset(&t->pending.signal, SIGKILL);
1000      
 signal_wake_up(t, 1);
1001     }
1002 
}

next_thread定义在include/linux/sched.h中，如下

651  static inline struct task_struct
*next_thread(const struct task_struct *p)
1652  {
1653     return
list_entry(rcu_dereference(p->thread_group.next),
1654      
      struct task_struct, thread_group);
1655 
}

其实就是通过task_struct中的thread_group队列来遍历线程组中的所有线程。
在其中，会在signal->flags中设置SIGNAL_GROUP_EXIT，同时，搜索线程组中所有进程，在每个线程中挂上一个SIGKILL信号，这样，当那些线程调度到运行的时候，就会处理SIGKILL信号，对于SIGKILL信号的处理，会调用do_group_exit，不过，当这次调用到do_group_exit的时候，将运行到1061行，然后就到了1076行的do_exit。这样，当线程组中的每个线程都运行过一遍后，整个线程组就退出了。

POSIX Thread Library (NPTL)使Linux内核可以非常有效的运行使用POSIX线程标准写的程序。这里有一个测试数据，在32位机下，NPTL成功启动100000个线程只用了2秒，而不使用NPTL将需要大约15分钟左右的时间。

历史

在内核2.6以前的调度实体都是进程，内核并没有真正支持线程。它是能过一个系统调用clone()来实现的，这个调用创建了一份调用进程的拷贝，跟fork()不同的是,这份进程拷贝完全共享了调用进程的地址空间。LinuxThread就是通过这个系统调用来提供线程在内核级的支持的(许多以前的线程实现都完全是在用户态，内核根本不知道线程的存在)。非常不幸的是，这种方法有相当多的地方没有遵循POSIX标准，特别是在信号处理，调度，进程间通信原语等方面。

很显然，为了改进LinuxThread必须得到内核的支持，并且需要重写线程库。为了实现这个需求，开始有两个相互竞争的项目：IBM启动的NGTP(Next
Generation POSIX
Threads)项目，以及Redhat公司的NPTL。在2003年的年中，IBM放弃了NGTP，也就是大约那时，Redhat发布了最初的NPTL。

NPTL最开始在redhat linux 9里发布，现在从RHEL3起内核2.6起都支持NPTL，并且完全成了GNU C库的一部分。

设计

NPTL使用了跟LinuxThread相同的办法，在内核里面线程仍然被当作是一个进程，并且仍然使用了clone()系统调用(在NPTL库里调用)。但是，NPTL需要内核级的特殊支持来实现，比如需要挂起然后再唤醒线程的线程同步原语futex.

NPTL也是一个1*1的线程库，就是说，当你使用pthread_create()调用创建一个线程后，在内核里就相应创建了一个调度实体，在linux里就是一个新进程，这个方法最大可能的简化了线程的实现。

除NPTL的1*1模型外还有一个m*n模型，通常这种模型的用户线程数会比内核的调度实体多。在这种实现里，线程库本身必须去处理可能存在的调度，这样在线程库内部的上下文切换通常都会相当的快，因为它避免了系统调用转到内核态。然而这种模型增加了线程实现的复杂性,并可能出现诸如优先级反转的问题，此外，用户态的调度如何跟内核态的调度进行协调也是很难让人满意。

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/guosha/archive/2008/09/22/2960186.aspx

---------------------------------------------------------------------------

有一个问题一直没有想清楚，请教牛人，谢谢。
资源描述：
        系统环境：4个CPU, linux2.6内核，NPTL，SMP。
       
问题：
        (进程是资源单元；线程是执行单元。)
       
一个进程拥有4个线程，这4个线程同时在4个CPU上运行。
        问1：系统的调度单位是进程还是线程呢？(针对linux2.6内核)；
 
     
问2：如果调度单位是线程，每个线程都应该运行在同一个进程的上下文中，如果这样的话就需要对进程上下文加锁；同时如果有其他进程的线程也运行在同一个CPU上，那么进程的上下文切换会非常频繁？
 
           如果调度单位是进程，又没有办法解释同一个进程中的4个线程同时跑在4个CPU上？
       
问3：看到一篇文章说“SMP的负载均衡是按进程数计算的”不知道是否正确。
           
 如果正确，同一个进程的所有线程应该分配到同一个CPU上，不解？

答：

Linux2.6内核实现的是NPTL