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

转

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

pid，从字面上是process id，但其实是thread id。
tgid，从字面上，应该是thread group id，也就是真正的process id。
这一点，可以从系统调用getpid和gettid中看出来（位于kernel/timer.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上，不解？

答：