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上,不解?

答:

问题1:
   
linux内核中的调度单位总是一个进程。但是内核中有对线程的支持。
问题2:
   
既然在linux的线程就是一个进程.就不存在什么所有线程都在同一进程上下文。而且这个观点是错误的。一个线程是什么?线程只是一个进程的子集。也就是说是一个进程上下文的子集。而且每个线程的上下文的很少有交集。除非两个线程之间需要通信。linux中进程所传建的线程本质就是进程。只不过这些子进程和父进程看到的都是同一地址空间,共享资源。
恢复一个线程的运行只需要恢复线程上下文。既然是线程在运行,何来进程上下文? 线程的实现方式不同.但原理本质一样。
既然linux的调度单位是进程,而线程又是以进程实现的.所以进程的四个线程在4个CPU上同时运行是可能的.只要不存在互斥。

问题3:
   
这个是高级问题... 不清楚...楼主可以goolge下.应该很多文章和论文的。

上一篇:netty解决tcp粘包和拆包问题


下一篇:Failed to start bean ‘documentationPluginsBootstrapper’; nested exception is java.lang.NullPointerEx