有关linux下进程与线程看过好多文章,我觉的这篇可以说最精典一.基础知识:线程和进程根据教科书上的定义,进程是资源管理的最小单位,线程是程序执行的最小单位,linux下进程与线程Linux。在操作系统设计上,从进程演变出线程,最主要的目的就是更好的支持SMP以及降低(进程/线程
有关linux下进程与线程看过好多文章,我觉的这篇可以说最精典
一.基础知识:线程和进程
根据教科书上的定义,进程是资源管理的最小单位linux通配符,线程是程序执行的最小单位。在操作系统设计上,从进程演变出线程,最主要的目的就是更好的支持SMP以及降低(进程/线程)上下文切换开支。
无论根据如何的分法,一个进程起码须要一个线程作为它的指令执行体,进程管理着资源(例如cpu、内存、文件等等),而将线程分配到某个cpu上执行。一个进程其实可以拥有多个线程,此时,假如进程运行在SMP机器上,它就可以同时使用多个cpu来执行各个线程,达到最大程度的并行,以提升效率;同时,就算是在单cpu的机器上,采用多线程模型来设计程序,正如当初采用多进程模型取代单进程模型一样,使设计更简练、功能更完备,程序的执行效率也更高,比如采用多个线程响应多个输入,而此时多线程模型所实现的功能实际上也可以用多进程模型来实现,而与前者相比,线程的上下文切换开支就比进程要小多了,从语义上来说,同时响应多个输入这样的功能,实际上就是共享了除cpu以外的所有资源的。
针对线程模型的两大意义,分别开发出了核心级线程和用户级线程两种线程模型,分类的标准主要是线程的调度者在核内还是在核外。后者更利于并发使用多处理器的资源,而前者则更多考虑的是上下文切换开支。在目前的商用系统中,一般都将二者结合上去使用,既提供核心线程以满足smp系统的须要,也支持用线程库的形式在用户态实现另一套线程机制,此时一个核心线程同时成为多个用户态线程的调度者。正如好多技术一样,"混和"一般都能带来更高的效率,但同时也带来更大的实现难度,出于"简单"的设计思路,Linux从一开始就没有实现混和模型的计划,但它在实现上采用了另一种思路的"混和"。
在线程机制的具体实现上,可以在操作系统内核上实现线程,也可以在核外实现,前者似乎要求核内起码实现了进程,而后者则通常要求在核内同时也支持进程。核心级线程模型其实要求后者的支持,而用户级线程模型则不一定基于前者实现。这些差别,正如前所述,是两种分类方法的标准不同带来的。
当核内既支持进程也支持线程时,就可以实现线程-进程的"多对多"模型,即一个进程的某个线程由核内调度,而同时它也可以作为用户级线程池的调度者,选择合适的用户级线程在其空间中运行。这就是上面提及的"混和"线程模型,既可满足多处理机系统的须要,也可以最大限度的减少调度开支。绝大多数商业操作系统(如DigitalUnix、Solaris、Irix)都采用的这些才能完全实现POSIX1003.1c标准的线程模型。在核外实现的线程又可以分为"一对一"、"多对一"两种模型,后者用一个核心进程(其实是轻量进程)对应一个线程,将线程调度等同于进程调度,交给核心完成,而前者则完全在核外实现多线程,调度也在用户态完成。前者就是上面提及的单纯的用户级线程模型的实现方法,其实,这些核外的线程调度器实际上只须要完成线程运行栈的切换,调度开支十分小,但同时由于核心讯号(无论是同步的还是异步的)都是以进程为单位的,因此难以定位到线程,所以这些实现方法不能用于多处理器系统,而这个需求正显得越来越大,因而,在现实中,纯用户级线程的实现,除算法研究目的以外,几乎早已消失了。
Linux内核只提供了轻量进程的支持,限制了更高效的线程模型的实现,但Linux注重优化了进程的调度开支,一定程度上也填补了这一缺陷。目前最流行的线程机制LinuxThreads所采用的就是线程-进程"一对一"模型,调度交给核心,而在用户级实现一个包括讯号处理在内的线程管理机制。Linux-LinuxThreads的运行机制正是本文的描述重点。
二.Linux2.4内核中的轻量进程实现
最初的进程定义都包含程序、资源及其执行三部份,其中程序一般指代码,资源在操作系统层面上一般包括显存资源、IO资源、信号处理等部份,而程序的执行一般理解为执行上下文,包括对cpu的占用,后来发展为线程。在线程概念出现曾经,为了降低进程切换的开支,操作系统设计者逐步修正进程的概念,逐步准许将进程所占有的资源从其主体剥离下来,容许个别进程共享一部份资源,比如文件、信号,数据显存,甚至代码,这就发展出轻量进程的概念。Linux内核在2.0.x版本就早已实现了轻量进程,应用程序可以通过一个统一的clone()系统调用插口,用不同的参数指定创建轻量进程还是普通进程。在内核中,clone()调用经过参数传递和解释后会调用do_fork(),这个核内函数同时也是fork()、vfork()系统调用的最终实现:
intdo_fork(unsignedlongclone_flags,unsignedlongstack_start,
structpt_regs*regs,unsignedlongstack_size)
其中的clone_flags取自以下宏的"或"值:
#defineCSIGNAL0xx000000000000ff/*signalmasktobesentatexit*/
#defineCLONE_VM0x00000100/*setifVMsharedbetweenprocesses*/
#defineCLONE_FS0x00000200/*setiffsinfosharedbetweenprocesses*/
#defineCLONE_FILES0x00000400/*setifopenfilessharedbetweenprocesses*/
#defineCLONE_SIGHAND0x00000800/*setifsignalhandlersandblockedsignalsshared*/
#defineCLONE_PID0x00001000/*setifpidshared*/
#defineCLONE_PTRACE0x00002000/*setifwewanttolettracingcontinueonthechildtoo*/
#defineCLONE_VFORK0x00004000/*setiftheparentwantsthechildtowakeituponmm_release*/
#defineCLONE_PARENT0x00008000/*setifwewanttohavethesameparentasthecloner*/
#defineCLONE_THREAD0x00010000/*Samethreadgroup?*/
#defineCLONE_NEWNS0x00020000/*Newnamespacegroup?*/
#defineCLONE_SIGNAL(CLONE_SIGHAND|CLONE_THREAD)
在do_fork()中,不同的clone_flags将造成不同的行为,对于LinuxThreads,它使用(CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND)参数来调用clone()创建"线程",表示共享显存、共享文件系统访问计数、共享文件描述符表,以及共享讯号处理方法。本节就针对这几个参数,瞧瞧Linux内核是怎样实现这种资源的共享的。
1.CLONE_VM
do_fork()须要调用copy_mm()来设置task_struct中的mm和active_mm项,这两个mm_struct数据与进程所关联的显存空间相对应。假如do_fork()时指定了CLONE_VM开关,copy_mm()将把新的task_struct中的mm和active_mm设置成与current的相同,同时提升该mm_struct的使用者数量(mm_struct::mm_users)。也就是说,轻量级进程与父进程共享显存地址空间,由右图示意可以看出mm_struct在进程中的地位:
2.CLONE_FS
task_struct中借助fs(structfs_struct*)记录了进程所在文件系统的根目录和当前目录信息,do_fork()时调用copy_fs()复制了这个结构;而对于轻量级进程则仅降低fs->count计数,与父进程共享相同的fs_struct。也就是说,轻量级进程没有独立的文件系统相关的信息,进程中任何一个线程改变当前目录、根目录等信息都将直接影响到其他线程。
3.CLONE_FILES
一个进程可能打开了一些文件,在进程结构task_struct中借助files(structfiles_struct*)来保存进程打开的文件结构(structfile)信息,do_fork()中调用了copy_files()来处理这个进程属性;轻量级进程与父进程是共享该结构的,copy_files()时仅降低files->count计数。这一共享致使任何线程都能访问进程所维护的打开文件,对它们的操作会直接反映到进程中的其他线程。
4.CLONE_SIGHAND
每一个Linux进程都可以自行定义对讯号的处理方法,在task_struct中的sig(structsignal_struct)中使用一个structk_sigaction结构的链表来保存这个配置信息,do_fork()中的copy_sighand()负责复制该信息;轻量级进程不进行复制,而仅仅降低signal_struct::count计数,与父进程共享该结构。也就是说,子进程与父进程的讯号处理方法完全相同,但是可以互相修改。
do_fork()中所做的工作好多,在此不详尽描述。对于SMP系统,所有的进程fork下来后,都被分配到与父进程相同的cpu上,仍然到该进程被调度时才能进行cpu选择。
虽然Linux支持轻量级进程,但并不能说它就支持核心级线程,由于Linux的"线程"和"进程"实际上处于一个调度层次,共享一个进程标示符空间,这些限制致使不可能在Linux上实现完全意义上的POSIX线程机制,因而诸多的Linux线程库实现尝试都只能尽可能实现POSIX的绝大部份语义,并在功能上尽可能迫近。
三.LinuxThread的线程机制
LinuxThreads是目前Linux平台上使用最为广泛的线程库,由XavierLeroy(Xavier.Leroy@inria.fr)负责开发完成,并已绑定在GLIBC中发行。它所实现的就是基于核心轻量级进程的"一对一"线程模型,一个线程实体对应一个核心轻量级进程,而线程之间的管理在核外函数库中实现。
1.线程描述数据结构及实现限制
LinuxThreads定义了一个struct_pthread_descr_struct数据结构来描述线程,并使用全局字段变量__pthread_handles来描述和引用进程所辖线程。在__pthread_handles中的前两项,LinuxThreads定义了两个全局的系统线程:__pthread_initial_thread和__pthread_manager_thread,并用__pthread_main_thread表征__pthread_manager_thread的父线程(初始为__pthread_initial_thread)。
struct_pthread_descr_struct是一个双环数组结构,__pthread_manager_thread所在的数组仅包括它一个元素,实际上,__pthread_manager_thread是一个特殊线程,LinuxThreads仅使用了其中的errno、p_pid、p_priority等三个域。而__pthread_main_thread所在的链则将进程中所有用户线程串在了一起,笔记本资料《linux下进程与线程Linux》()。经过一系列pthread_create()以后产生的__pthread_handles字段将如右图所示:
图2__pthread_handles链表结构
新创建的线程将首先在__pthread_handles字段中抢占一项,之后通过数据结构中的链表针连入以__pthread_main_thread为首表针的数组中。这个数组的使用在介绍线程的创建和释放的时侯将谈到。
LinuxThreads遵守POSIX1003.1c标准,其中对线程库的实现进行了一些范围限制,例如进程最大线程数,线程私有数据区大小等等。在LinuxThreads的实现中,基本遵照这种限制,但也进行了一定的改动,改动的趋势是放松或则说扩大这种限制,使编程愈加便捷。那些限定宏主要集中在sysdeps/unix/sysv/linux/bits/local_lim.h(不同平台使用的文件位置不同)中,包括如下几个:
每进程的私有数据key数,POSIX定义_POSIX_THREAD_KEYS_MAX为128,LinuxThreads使用PTHREAD_KEYS_MAX,1024;私有数据释放时容许执行的操作数,LinuxThreads与POSIX一致,定义PTHREAD_DESTRUCTOR_ITERATIONS为4;每进程的线程数,POSIX定义为64,LinuxThreads减小到1024(PTHREAD_THREADS_MAX);线程运行栈最小空间大小,POSIX未指定,LinuxThreads使用PTHREAD_STACK_MIN,16384(字节)。
2.管理线程
"一对一"模型的用处之一是线程的调度由核心完成了,而其他例如线程取消、线程间的同步等工作,都是在核外线程库中完成的。在LinuxThreads中,专门为每一个进程构造了一个管理线程,负责处理线程相关的管理工作。当进程第一次调用pthread_create()创建一个线程的时侯才会创建(__clone())并启动管理线程。
在一个进程空间内,管理线程与其他线程之间通过一对"管理管线(manager_pipe[2])"来通信,该管线在创建管理线程之前创建,在成功启动了管理线程以后,管理管线的读端和写端分宫词给两个全局变量__pthread_manager_reader和__pthread_manager_request,以后,每位用户线程都通过__pthread_manager_request向管理线程发恳求,但管理线程本身并没有直接使用__pthread_manager_reader,管线的读端(manager_pipe[0])是作为__clone()的参数之一传给管理线程的,管理线程的工作主要就是窃听管线读端,并对从中取出的恳求做出反应。
创建管理线程的流程如下所示:
(全局变量pthread_manager_request年率为-1)
图3创建管理线程的流程
初始化结束后,在__pthread_manager_thread中记录了轻量级进程号以及核外分配和管理的线程id,2*PTHREAD_THREADS_MAX+1这个数值不会与任何常规用户线程id冲突。管理线程作为pthread_create()的调用者线程的子线程运行,而pthread_create()所创建的那种用户线程则是由管理线程来调用clone()创建,因而实际上是管理线程的子线程。(此处子线程的概念应当当成子进程来理解。)
__pthread_manager()就是管理线程的主循环所在,在进行一系列初始化工作后,步入while(1)循环。在循环中,线程以2秒为timeout查询(__poll())管理管线的读端。在处理恳求前,检测其父线程(也就是创建manager的主线程)是否已退出,倘若已退出就退出整个进程。假如有退出的子线程须要清除,则调用pthread_reap_children()清除。
之后才是读取管线中的恳求,按照恳求类型执行相应操作(switch-case)。具体的恳求处理,源码中比较清楚,这儿就不赘言了。
3.线程栈
在LinuxThreads中,管理线程的栈和用户线程的栈是分离的,管理线程在进程堆中通过malloc()分配一个THREAD_MANAGER_STACK_SIZE字节的区域作为自己的运行栈。
用户线程的栈分配办法随着体系结构的不同而不同,主要依据两个宏定义来分辨,一个是NEED_SEPARATE_REGISTER_STACK,这个属性仅在IA64平台上使用;另一个是FLOATING_STACK宏,在i386等少数平台上使用,此时用户线程栈由系统决定具体位置并提供保护。与此同时,用户还可以通过线程属性结构来指定使用用户自定义的栈。因篇幅所限,这儿只能剖析i386平台所使用的两种栈组织形式:FLOATING_STACK方法和用户自定义方法。
在FLOATING_STACK形式下,LinuxThreads借助mmap()从内核空间中分配8MB空间(i386系统缺省的最大栈空间大小,假若有运行限制(rlimit),则根据运行限制设置),使用mprotect()设置其中第一页为非访问区。该8M空间的功能分配如右图:
图4栈结构示意
低地址被保护的页面拿来检测栈溢出。
对于用户指定的栈,在根据指针对界后,设置线程栈顶,并估算出栈底,不做保护,正确性由用户自己保证。
不论哪种组织形式,线程描述结构总是坐落栈顶邻近堆栈的位置。
4.线程id和进程id
每位LinuxThreads线程都同时具有线程id和进程id,其中进程id就是内核所维护的进程号,而线程id则由LinuxThreads分配和维护。
__pthread_initial_thread的线程id为PTHREAD_THREADS_MAX,__pthread_manager_thread的是2*PTHREAD_THREADS_MAX+1,第一个用户线程的线程id为PTHREAD_THREADS_MAX+2,随后第n个用户线程的线程id遵守以下公式:
tid=n*PTHREAD_THREADS_MAX+n+1
这些分配方法保证了进程中所有的线程(包括早已退出)都不会有相同的线程id,而线程id的类型pthread_t定义为无符号长整型(unsignedlongint),也保证了有理由的运行时间内线程id不会重复。
从线程id查找线程数据结构是在pthread_handle()函数中完成的,实际上只是将线程号按PTHREAD_THREADS_MAX取模,得到的就是该线程在__pthread_handles中的索引。
5.线程的创建
在pthread_create()向管理线程发送REQ_CREATE恳求以后linux进程与线程 内核,管理线程即调用pthread_handle_create()创建新线程。分配栈、设置thread属性后,以pthread_start_thread()为函数入口调用__clone()创建并启动新线程。pthread_start_thread()读取自身的进程id号存入线程描述结构中,并按照其中记录的调度方式配置调度。一切打算就绪后,再调用真正的线程执行函数,并在此函数返回后调用pthread_exit()清除现场。
6.LinuxThreads的不足
因为Linux内核的限制以及实现难度等等缘由,LinuxThreads并不是完全POSIX兼容的linux进程与线程 内核,在它的发行README中有说明。
1)进程id问题
这个不足是最关键的不足,导致的缘由牵连到LinuxThreads的"一对一"模型。
Linux内核并不支持真正意义上的线程,LinuxThreads是用与普通进程具有同样内核调度视图的轻量级进程来实现线程支持的。这种轻量级进程拥有独立的进程id,在进程调度、信号处理、IO等方面享有与普通进程一样的能力。在源码阅读者看来,就是Linux内核的clone()没有实现对CLONE_PID参数的支持。
在内核do_fork()中对CLONE_PID的处理是这样的:
if(clone_flags&CLONE_PID){
if(current->pid)
gotofork_out;
这段代码表明linux软件工程师,目前的Linux内核仅在pid为0的时侯认可CLONE_PID参数,实际上,仅在SMP初始化,手工创建进程的时侯才能使用CLONE_PID参数。
根据POSIX定义,同一进程的所有线程应当共享一个进程id和父进程id,这在目前的"一对一"模型下是难以实现的。
2)讯号处理问题
因为异步讯号是内核以进程为单位分发的,而LinuxThreads的每位线程对内核来说都是一个进程,且没有实现"线程组",为此,个别语义不符合POSIX标准,例如没有实现向进程中所有线程发送讯号,README对此作了说明。
假如核心不提供实时讯号,LinuxThreads将使用SIGUSR1和SIGUSR2作为内部使用的restart和cancel讯号,这样应用程序就不能使用这两个本来为用户保留的讯号了。在Linuxkernel2.1.60之后的版本都支持扩充的实时讯号(从_SIGRTMIN到_SIGRTMAX),因而不存在这个问题。
个别讯号的缺省动作无法在现行体系上实现,例如SIGSTOP和SIGCONT,LinuxThreads只能将一个线程挂起,而未能挂起整个进程。
3)线程总量问题
LinuxThreads将每位进程的线程最大数量定义为1024,但实际上这个数值还遭到整个系统的总进程数限制,这又是因为线程虽然是核心进程。
在kernel2.4.x中,采用一套全新的总进程数估算方式,促使总进程数基本上仅受限于化学显存的大小,估算公式在kernel/fork.c的fork_init()函数中:
max_threads=mempages/(THREAD_SIZE/PAGE_SIZE)/8
在i386上,THREAD_SIZE=2*PAGE_SIZE,PAGE_SIZE=2^12(4KB),mempages=化学显存大小/PAGE_SIZE,对于256M的显存的机器,mempages=256*2^20/2^12=256*2^8,此时最大线程数为4096。
但为了保证每位用户(不仅root)的进程总量不至于占用一半以上化学显存,fork_init()中继续指定:
init_task.rlim[RLIMIT_NPROC].rlim_cur=max_threads/2;
init_task.rlim[RLIMIT_NPROC].rlim_max=max_threads/2;
这种进程数量的检测都在do_fork()中进行,因而,对于LinuxThreads来说,线程总量同时受这三个诱因的限制。
4)管理线程问题
管理线程容易成为困局,这是这些结构的弊病;同时,管理线程又负责用户线程的清除工作,因而,虽然管理线程早已屏蔽了大部份的讯号,但一旦管理线程死亡,用户线程就不得不手工清除了,但是用户线程并不晓得管理线程的状态,然后的线程创建等恳请将无人处理。
5)同步问题
LinuxThreads中的线程同步很大程度上是构建在讯号基础上的,这些通过内核复杂的讯号处理机制的同步方法,效率仍然是个问题。
6)其他POSIX兼容性问题
Linux中好多系统调用,根据语义都是与进程相关的,例如nice、setuid、setrlimit等,在目前的LinuxThreads中,这种调用都仅仅影响调用者线程。
7)实时性问题
线程的引入有一定的实时性考虑,但LinuxThreads暂时不支持,例如调度选项,目前还没有实现。除了LinuxThreads这么,标准的Linux在实时性上考虑都甚少。