linux线程调度源码解析

㈠ linux里面,进程与线程到底有什么本质的区别

线程：是进程中执行的一条路径，是系统调度的最小单位。

进程：是正在运行的程序，是系统分配资源的最小单位。

线程与进程关系

1.一个进程可以有多个线程，一个线程只能属于一个进程。

2.同一个进程下的所有线程共享该进程下的所有资源。

3.真正在处理机上运行的是线程，不是进程，线程是进程内的一个执行单元，是进程内的可调度实体。

Linux线程与进程区别

进程：

优点：多进程可以同时利用多个CPU，能够同时进行多个操作。

缺点：耗费资源(创建一个进程重新开辟内存空间)。

进程不是越多越好，一般进程个数等于cpu个数。

线程：

优点：共享内存，尤其是进行IO操作(网络、磁盘)的时候(IO操作很少用cpu)，可以使用多线程执行并发操作。

缺点：抢占资源。

㈡ 麻烦解释一下linux下进程和线程有什么区别和联系，linux下多线程和多进程通信的实现方法，请通俗解释

兄弟看到你这么高的分我就找了些资料：也算是对昨天学的知识总结一下吧
一、先说概念不管是windows还是linux下的进程和线程概念都是一样的，只是管理进程和线程的方式不一样，这个是前提，到时候你可别问我windows下进程和线程啊。这个涉及到操作系统原理。下面给你解答。
说道进程不得不提作业这个名词 ，我想兄弟你电脑里不会有一个程序吧对不？当你的系统启动完毕后你看看你的任务管理器里是不是有很多进程呢？那么多程序是怎么调如内存呢？能理解吗？这里要明白程序和进程的关系，程序是你磁盘上的一个文件，当你需要它时进入内存后才成为进程，好比QQ在磁盘上就是一个文件而已，只有进入了内存才成为进程，进程是活动的。QQ要扫描你文件啊，记录你聊天记录啊，偷偷上传个啥东西什么的你也不知道对不，他是活动的。这个能明白吗？
再看作业，这个作业可不是你写作业的那个作业啊。系统一看好家伙你个QQ那么大的家伙你想一下子进入内存啊？没门！慢慢来嘛，系统就把QQ程序分为好几块，这几块不能乱分的，要符合自然结构就是循环啦选择啦这样的结构，你把人家循环结构咔嚓截断了，怎么让人家QQ运行啊？这就是作业要一块一块的进入内存，同时要为作业产生JCB（JOB CONTROL BLOCK)作业控制块，你进入内存不能乱跑啊，要听系统的话，你要是进入系统自己的内存。框一下，内存不能读写 对话框就出来了，严重点直接蓝脸给你！你懂得。这是window下的，linux下直接给你报错！没事了就！所一系统通过jcb控制进程。JCB包含了进程号优先级好多内容，你打开你的windows任务管理器看看进程是不是有好多属性啊？那就是PCB（PRCESS，CONTROL BLOCK）同理作业也包含那些内容只是多少而已。下面写出进程特点：
1、进程是分配计算机资源最小的单位。你想啊人是要用程序干活的吧？你把程序调入内存成了就成了进程，所以说进程是分配资源的最小单位。你在linux下打开终端输入top命令看是不是有好多进程？
2、进程有操作系统为作业产生。有“父进程”产生“子进程”之间是父子关系，并可以继续向下产生“子进程”。还拿QQ来说，你双击QQ.exe。QQ启动了输入账号密码打开主界面了。这时候你要聊天，QQ进程赶紧产生个“儿子”说 “儿子你去陪主人聊天去吧。这样子进程产生了。突然你想看美女要传照片这时候那个”儿子“有”生“了一个”儿子“说”儿子“你去传照片。那个“儿子领到任务去传照片了。这时你想关了QQ，QQ提示你说”你还有个“儿子”和“孙子”还在干活呢你真要结束吗？你蒽了确定。QQ对他“儿子”（你聊天窗口）说：”儿子啊对不起了，主人要关闭我你也不能活啊“咔嚓一下”儿子“死了，儿子死之前对他儿子说：“儿子啊你爷爷不让我活了，你也别活了咔嚓孙子也死了。最后世界安静了。这就是进程的父子关系。能明白吗？记住：进程之活动在内存中。不能使用CPU，只管分配资源。
再说线程：线程也产生在内存中并且在内存中存在相当长的时间，但它的活动区域主要在CPU中，并且运行和灭亡都存在于CPU中，可以这么说，线程是程序中能被系统调度进入CPU中最小程序单位，它能直接使用进程分配的CPU的资源。
还拿QQ来说当你要传文件时QQ总要判断一下文件的扩展名吧，ok这时那个”儿子“赶紧对它爸爸说我需要一个线程判断扩展名QQ赶紧对一个管这个的线程说：”快点去CPU里计算下那个扩展名是什么然后向主人报告计算完了就“死了”消亡了，但是它的线程还在内存中！还等着你下一次传文件然后计算然后消亡！
线程之间是相互独立的。一个在CPU，一个在内存里还能有关系吗对不？CPU在每一个瞬间只能进入一个线程，当线程进入CPU时立即产生一个新的线程，新线程仍停留在内存中，就好比上面那个传文件还会等着你再传文件再计算扩展名。
线程相对线程是独立的，但它在内存中并不是独立的，这就好比你不开QQ能用QQ传输文件吗？它只存在与进程分配的资源中，也就是说计算扩展名这个线程只能停留在QQ这个进程中，不能跑到别的进程里！！相当于程序产生了新的进程和线程，进程向CPU申请资源，再有线程来使用，他们都是为程序服务的只是分工不同！
因为你没提问linux下是怎么管理进程和线程的所以我就不回答了，这个问题我建议你还是看看《笨兔兔的故事》里面讲到了linux是怎么管理进程和线程的。挺幽默的比我说得还好。
你第二个问题说实话我回答不了你！我想你现在连进程和线程还没理解第二个你更理解不了了你说对不？我猜的其实你用C/C++不管是在windows下编程还是在Linux下编程思想都是一样的对吧，如果你理解了在windows下线程间通信，在linux更没问题了！
参考资料：黑客手册2009合订本非安全第一二季244页，245页，328页，329页，398页，399页
浅谈操作系统原理 （一 二三）
ubuntu中文论坛 笨兔兔的故事
http://forum.ubuntu.org.cn/viewtopic.php?f=120&t=267518
希望我的回答你能理解

㈢ linux中内核线程与用户线程在调度上有什么区别

用户级实现线程时，内核调度是以进程为单位的，内核并不知道用户级线程的存在，因此某个用户级线程的阻塞即会引起整个进程的阻塞。
内核级线程阻塞时，内核完全可以调度同进程内的其它线程运行，也就是没有阻塞整个线程

㈣ linux调度是基于进程还是线程

在LINUX系统之中，被调度的应该是进程。因为只有进程才拥有一个独立的上下文环境，是分配系统资源的最小单位……而线程在SMP体系中加速了执行的效率……
在LINUX之中，线程也可称作轻量级进程，它能享有自己的堆栈，线程ID等独立资源，但大多还是要依赖其创建进程，比如地址空间，信号，文件句柄……

㈤ Linux如何进行进程调度引入线程机制后，进程管理内容包括哪些

进程调度的算法有很多，简单来说就是每个进程都有一个自己的时间片，时间到了，就会被挂起，然后系统挑选下一个合适的进程来执行。至于谁合适，那就要看算法了，优先级，是不是饥饿，I/O型还是运算型，都要考虑的。
调度算法比较复杂庞大，不是这里说的清楚的。
进程切换的过程大概就是保存当前上下文，也就是各种寄存器的状态，包括指令寄存器。然后把下一个进程的上下文加载上来。
有了线程机制之后，进程管理主要管理线程之间的数据共享，管理进程地址空间，进程的交换空间。因为这些资源是属于进程的，线程之间是共享的。
​现代操作系统调度基本是围绕线程进行的，进程更多的是起到资源管理分配的作用。

㈥ linux系统中线程同步实现机制有哪些

LinuxThread的线程机制

LinuxThreads是目前Linux平台上使用最为广泛的线程库，由Xavier Leroy ([email protected]) 负责开发完成，并已绑定在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所在的链则将进程中所有用户线程串在了一起。经过一系列 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分配和维护。

㈦ 进程调度的Linux 原理

1，SCHED_OTHER 分时调度策略，
2，SCHED_FIFO实时调度策略，先到先服务
3，SCHED_RR实时调度策略，时间片轮转
实时进程将得到优先调用，实时进程根据实时优先级决定调度权值，分时进程则通过nice和counter值决定权值，nice越小，counter越大，被调度的概率越大，也就是曾经使用了cpu最少的进程将会得到优先调度。
SHCED_RR和SCHED_FIFO的不同：
当采用SHCED_RR策略的进程的时间片用完，系统将重新分配时间片，并置于就绪队列尾。放在队列尾保证了所有具有相同优先级的RR任务的调度公平。
SCHED_FIFO一旦占用cpu则一直运行。一直运行直到有更高优先级任务到达或自己放弃。
如果有相同优先级的实时进程（根据优先级计算的调度权值是一样的）已经准备好，FIFO时必须等待该进程主动放弃后才可以运行这个优先级相同的任务。而RR可以让每个任务都执行一段时间。
相同点：
RR和FIFO都只用于实时任务。
创建时优先级大于0(1-99)。
按照可抢占优先级调度算法进行。
就绪态的实时任务立即抢占非实时任务。
所有任务都采用linux分时调度策略时。
1，创建任务指定采用分时调度策略，并指定优先级nice值(-20~19)。
2，将根据每个任务的nice值确定在cpu上的执行时间(counter)。
3，如果没有等待资源，则将该任务加入到就绪队列中。
4，调度程序遍历就绪队列中的任务，通过对每个任务动态优先级的计算(counter+20-nice)结果，选择计算结果最大的一个去运行，当这个时间片用完后(counter减至0)或者主动放弃cpu时，该任务将被放在就绪队列末尾(时间片用完)或等待队列(因等待资源而放弃cpu)中。
5，此时调度程序重复上面计算过程，转到第4步。
6，当调度程序发现所有就绪任务计算所得的权值都为不大于0时，重复第2步。
所有任务都采用FIFO时，
1，创建进程时指定采用FIFO，并设置实时优先级rt_priority(1-99)。
2，如果没有等待资源，则将该任务加入到就绪队列中。
3，调度程序遍历就绪队列，根据实时优先级计算调度权值(1000+rt_priority)，选择权值最高的任务使用cpu，该FIFO任务将一直占有cpu直到有优先级更高的任务就绪(即使优先级相同也不行)或者主动放弃(等待资源)。
4，调度程序发现有优先级更高的任务到达(高优先级任务可能被中断或定时器任务唤醒，再或被当前运行的任务唤醒，等等)，则调度程序立即在当前任务堆栈中保存当前cpu寄存器的所有数据，重新从高优先级任务的堆栈中加载寄存器数据到cpu，此时高优先级的任务开始运行。重复第3步。
5，如果当前任务因等待资源而主动放弃cpu使用权，则该任务将从就绪队列中删除，加入等待队列，此时重复第3步。
所有任务都采用RR调度策略时
1，创建任务时指定调度参数为RR，并设置任务的实时优先级和nice值(nice值将会转换为该任务的时间片的长度)。
2，如果没有等待资源，则将该任务加入到就绪队列中。
3，调度程序遍历就绪队列，根据实时优先级计算调度权值(1000+rt_priority)，选择权值最高的任务使用cpu。
4，如果就绪队列中的RR任务时间片为0，则会根据nice值设置该任务的时间片，同时将该任务放入就绪队列的末尾。重复步骤3。
5，当前任务由于等待资源而主动退出cpu，则其加入等待队列中。重复步骤3。
系统中既有分时调度，又有时间片轮转调度和先进先出调度
1，RR调度和FIFO调度的进程属于实时进程，以分时调度的进程是非实时进程。
2，当实时进程准备就绪后，如果当前cpu正在运行非实时进程，则实时进程立即抢占非实时进程。
3，RR进程和FIFO进程都采用实时优先级做为调度的权值标准，RR是FIFO的一个延伸。FIFO时，如果两个进程的优先级一样，则这两个优先级一样的进程具体执行哪一个是由其在队列中的未知决定的，这样导致一些不公正性(优先级是一样的，为什么要让你一直运行？)，如果将两个优先级一样的任务的调度策略都设为RR，则保证了这两个任务可以循环执行，保证了公平。 调度程序运行时，要在所有处于可运行状态的进程之中选择最值得运行的进程投入运行。选择进程的依据是什么呢？在每个进程的task_struct 结构中有这么四项：
policy， priority ， counter， rt_priority
这四项就是调度程序选择进程的依据.其中，policy是进程的调度策略，用来区分两种进程-实时和普通；priority是进程(实时和普通)的优先级；counter 是进程剩余的时间片，它的大小完全由priority决定；rt_priority是实时优先级，这是实时进程所特有的，用于实时进程间的选择。
首先，Linux 根据policy从整体上区分实时进程和普通进程，因为实时进程和普通进程度调度是不同的，它们两者之间，实时进程应该先于普通进程而运行，然后，对于同一类型的不同进程，采用不同的标准来选择进程：
对于普通进程，Linux采用动态优先调度，选择进程的依据就是进程counter的大小。进程创建时，优先级priority被赋一个初值，一般为0～70之间的数字，这个数字同时也是计数器counter的初值，就是说进程创建时两者是相等的。字面上看，priority是“优先级”、counter是“计数器”的意思，然而实际上，它们表达的是同一个意思-进程的“时间片”。Priority代表分配给该进程的时间片，counter表示该进程剩余的时间片。在进程运行过程中，counter不断减少，而priority保持不变，以便在counter变为0的时候（该进程用完了所分配的时间片）对counter重新赋值。当一个普通进程的时间片用完以后，并不马上用priority对counter进行赋值，只有所有处于可运行状态的普通进程的时间片(p->；；counter==0)都用完了以后，才用priority对counter重新赋值，这个普通进程才有了再次被调度的机会。这说明，普通进程运行过程中，counter的减小给了其它进程得以运行的机会，直至counter减为0时才完全放弃对CPU的使用，这就相对于优先级在动态变化，所以称之为动态优先调度。至于时间片这个概念，和其他不同操作系统一样的，Linux的时间单位也是“时钟滴答”，只是不同操作系统对一个时钟滴答的定义不同而已（Linux为10ms）。进程的时间片就是指多少个时钟滴答，比如，若priority为20，则分配给该进程的时间片就为20个时钟滴答，也就是20*10ms=200ms。Linux中某个进程的调度策略(policy)、优先级(priority)等可以作为参数由用户自己决定，具有相当的灵活性。内核创建新进程时分配给进程的时间片缺省为200ms(更准确的，应为210ms)，用户可以通过系统调用改变它。
对于实时进程，Linux采用了两种调度策略，即FIFO(先来先服务调度)和RR（时间片轮转调度）。因为实时进程具有一定程度的紧迫性，所以衡量一个实时进程是否应该运行，Linux采用了一个比较固定的标准。实时进程的counter只是用来表示该进程的剩余时间片，并不作为衡量它是否值得运行的标准，这和普通进程是有区别的。上面已经看到，每个进程有两个优先级，实时优先级就是用来衡量实时进程是否值得运行的。
这一切看来比较麻烦，但实际上Linux中的实现相当简单。Linux用函数goodness()来衡量一个处于可运行状态的进程值得运行的程度。该函数综合了上面提到的各个方面，给每个处于可运行状态的进程赋予一个权值(weight)，调度程序以这个权值作为选择进程的唯一依据。
Linux根据policy的值将进程总体上分为实时进程和普通进程，提供了三种调度算法：一种传统的Unix调度程序和两个由POSIX.1b(原名为POSIX.4)操作系统标准所规定的“实时”调度程序。但这种实时只是软实时，不满足诸如中断等待时间等硬实时要求，只是保证了当实时进程需要时一定只把CPU分配给实时进程。
非实时进程有两种优先级，一种是静态优先级，另一种是动态优先级。实时进程又增加了第三种优先级，实时优先级。优先级是一些简单的整数，为了决定应该允许哪一个进程使用CPU的资源，用优先级代表相对权值-优先级越高，它得到CPU时间的机会也就越大。
？ 静态优先级(priority)-不随时间而改变，只能由用户进行修改。它指明了在被迫和其他进程竞争CPU之前，该进程所应该被允许的时间片的最大值（但很可能的，在该时间片耗尽之前，进程就被迫交出了CPU）。
？ 动态优先级(counter)-只要进程拥有CPU，它就随着时间不断减小；当它小于0时，标记进程重新调度。它指明了在这个时间片中所剩余的时间量。
？ 实时优先级(rt_priority)-指明这个进程自动把CPU交给哪一个其他进程；较高权值的进程总是优先于较低权值的进程。如果一个进程不是实时进程，其优先级就是0，所以实时进程总是优先于非实时进程的（但实际上，实时进程也会主动放弃CPU）。
当policy分别为以下值时：
1) SCHED_OTHER：这是普通的用户进程，进程的缺省类型，采用动态优先调度策略，选择进程的依据主要是根据进程goodness值的大小。这种进程在运行时，可以被高goodness值的进程抢先。
2) SCHED_FIFO：这是一种实时进程，遵守POSIX1.b标准的FIFO(先入先出)调度规则。它会一直运行，直到有一个进程因I/O阻塞，或者主动释放CPU，或者是CPU被另一个具有更高rt_priority的实时进程抢先。在Linux实现中，SCHED_FIFO进程仍然拥有时间片-只有当时间片用完时它们才被迫释放CPU。因此，如同POSIX1.b一样，这样的进程就象没有时间片(不是采用分时)一样运行。Linux中进程仍然保持对其时间片的记录（不修改counter）主要是为了实现的方便，同时避免在调度代码的关键路径上出现条件判断语句 if (！(current->；；policy&；；SCHED_FIFO)){...}-要知道，其他大量非FIFO进程都需要记录时间片，这种多余的检测只会浪费CPU资源。（一种优化措施，不该将执行时间占10%的代码的运行时间减少到50%；而是将执行时间占90%的代码的运行时间减少到95%。0.9+0.1*0.5=0.95>；；0.1+0.9*0.9=0.91）
3) SCHED_RR：这也是一种实时进程，遵守POSIX1.b标准的RR(循环round-robin)调度规则。除了时间片有些不同外，这种策略与SCHED_FIFO类似。当SCHED_RR进程的时间片用完后，就被放到SCHED_FIFO和SCHED_RR队列的末尾。
只要系统中有一个实时进程在运行，则任何SCHED_OTHER进程都不能在任何CPU运行。每个实时进程有一个rt_priority，因此，可以按照rt_priority在所有SCHED_RR进程之间分配CPU。其作用与SCHED_OTHER进程的priority作用一样。只有root用户能够用系统调用sched_setscheler，来改变当前进程的类型(sys_nice，sys_setpriority)。
此外，内核还定义了SCHED_YIELD，这并不是一种调度策略，而是截取调度策略的一个附加位。如同前面说明的一样，如果有其他进程需要CPU，它就提示调度程序释放CPU。特别要注意的就是这甚至会引起实时进程把CPU释放给非实时进程。 真正执行调度的函数是schele(void)，它选择一个最合适的进程执行，并且真正进行上下文切换，使得选中的进程得以执行。而reschele_idle(struct task_struct *p)的作用是为进程选择一个合适的CPU来执行，如果它选中了某个CPU，则将该CPU上当前运行进程的need_resched标志置为1，然后向它发出一个重新调度的处理机间中断，使得选中的CPU能够在中断处理返回时执行schele函数，真正调度进程p在CPU上执行。在schele()和reschele_idle()中调用了goodness()函数。goodness()函数用来衡量一个处于可运行状态的进程值得运行的程度。此外，在schele()函数中还调用了schele_tail()函数；在reschele_idle()函数中还调用了reschele_idle_slow()。这些函数的实现对理解SMP的调度非常重要，下面一一分析这些函数。先给出每个函数的主要流程图，然后给出源代码，并加注释。
goodness()函数分析
goodness()函数计算一个处于可运行状态的进程值得运行的程度。一个任务的goodness是以下因素的函数：正在运行的任务、想要运行的任务、当前的CPU。goodness返回下面两类值中的一个：1000以下或者1000以上。1000或者1000以上的值只能赋给“实时”进程，从0到999的值只能赋给普通进程。实际上，在单处理器情况下，普通进程的goodness值只使用这个范围底部的一部分，从0到41。在SMP情况下，SMP模式会优先照顾等待同一个处理器的进程。不过，不管是UP还是SMP，实时进程的goodness值的范围是从1001到1099。
goodness()函数其实是不会返回-1000的，也不会返回其他负值。由于idle进程的counter值为负，所以如果使用idle进程作为参数调用goodness，就会返回负值，但这是不会发生的。
goodness()是个简单的函数，但是它是linux调度程序不可缺少的部分。运行队列中的每个进程每次执行schele时都要调度它，因此它的执行速度必须很快。
//在/kernel/sched.c中
static inline int goodness(struct task_struct * p， int this_cpu， struct mm_struct *this_mm)
{ int weight；
if (p->；；policy ！= SCHED_OTHER) {/*如果是实时进程，则*/
weight = 1000 + p->；；rt_priority；
goto out；
}
/* 将counter的值赋给weight，这就给了进程一个大概的权值，counter中的值表示进程在一个时间片内，剩下要运行的时间.*/
weight = p->；；counter；
if (！weight) /* weight==0，表示该进程的时间片已经用完，则直接转到标号out*/
goto out；
#ifdef __SMP__
/*在SMP情况下，如果进程将要运行的CPU与进程上次运行的CPU是一样的，则最有利，因此，假如进程上次运行的CPU与当前CPU一致的话，权值加上PROC_CHANGE_PENALTY，这个宏定义为20。*/
if (p->；；processor == this_cpu)
weight += PROC_CHANGE_PENALTY；
#endif
if (p->；；mm == this_mm) /*进程p与当前运行进程，是同一个进程的不同线程，或者是共享地址空间的不同进程，优先选择，权值加1*/
weight += 1；
weight += p->；；priority； /* 权值加上进程的优先级*/
out：
return weight； /* 返回值作为进程调度的唯一依据，谁的权值大，就调度谁运行*/
}
schele()函数分析
schele()函数的作用是，选择一个合适的进程在CPU上执行，它仅仅根据'goodness'来工作。对于SMP情况，除了计算每个进程的加权平均运行时间外，其他与SMP相关的部分主要由goodness()函数来体现。
流程：
①将prev和next设置为schele最感兴趣的两个进程：其中一个是在调用schele时正在运行的进程(prev)，另外一个应该是接着就给予CPU的进程（next）。注意：prev和next可能是相同的-schele可以重新调度已经获得cpu的进程.
②中断处理程序运行“下半部分”.
③内核实时系统部分的实现，循环调度程序（SCHED_RR）通过移动“耗尽的”RR进程-已经用完其时间片的进程-到队列末尾，这样具有相同优先级的其他RR进程就可以获得CPU了。同时，这补充了耗尽进程的时间片。
④由于代码的其他部分已经决定了进程必须被移进或移出TASK_RUNNING状态，所以会经常使用schele，例如，如果进程正在等待的硬件条件已经发生，所以如果必要，这个switch会改变进程的状态。如果进程已经处于TASK_RUNNING状态，它就无需处理了。如果它是可以中断的（等待信号），并且信号已经到达了进程，就返回TASK_RUNNING状态。在所以其他情况下（例如，进程已经处于TASK_UNINTERRUPTIBLE状态了），应该从运行队列中将进程移走。
⑤将p初始化为运行队列的第一个任务；p会遍历队列中的所有任务。
⑥c记录了运行队列中所有进程最好的“goodness”-具有最好“goodness”的进程是最易获得CPU的进程。goodness的值越高越好。
⑦遍历执行任务链表，跟踪具有最好goodness的进程。
⑧这个循环中只考虑了唯一一个可以调度的进程。在SMP模式下，只有任务不在cpu上运行时，即can_schele宏返回为真时，才会考虑该任务。在UP情况下，can_schele宏返回恒为真.
⑨如果循环结束后，得到c的值为0。说明运行队列中的所有进程的goodness值都为0。goodness的值为0，意味着进程已经用完它的时间片，或者它已经明确说明要释放CPU。在这种情况下，schele要重新计算进程的counter；新counter的值是原来值的一半加上进程的静态优先级（priortiy），除非进程已经释放CPU，否则原来counter的值为0。因此，schele通常只是把counter初始化为静态优先级。（中断处理程序和由另一个处理器引起的分支在schele搜寻goodness最大值时都将增加此循环中的计数器，因此由于这个原因计数器可能不会为0。显然，这很罕见。）在counter的值计算完成后，重新开始执行这个循环，找具有最大goodness的任务。
⑩如果schele已经选择了一个不同于前面正在执行的进程来调度，那么就必须挂起原来的进程并允许新的进程运行。这时调用switch_to来进行切换。

㈧ 如何实现linux下多线程之间的互斥与同步

Linux设备驱动中必须解决的一个问题是多个进程对共享资源的并发访问，并发访问会导致竞态，linux提供了多种解决竞态问题的方式，这些方式适合不同的应用场景。

Linux内核是多进程、多线程的操作系统，它提供了相当完整的内核同步方法。内核同步方法列表如下：
中断屏蔽
原子操作
自旋锁
读写自旋锁
顺序锁
信号量
读写信号量
BKL（大内核锁）
Seq锁
一、并发与竞态：
定义：
并发（concurrency）指的是多个执行单元同时、并行被执行，而并发的执行单元对共享资源（硬件资源和软件上的全局变量、静态变量等）的访问则很容易导致竞态（race conditions）。
在linux中，主要的竞态发生在如下几种情况：
1、对称多处理器（SMP）多个CPU
特点是多个CPU使用共同的系统总线，因此可访问共同的外设和存储器。
2、单CPU内进程与抢占它的进程
3、中断（硬中断、软中断、Tasklet、底半部）与进程之间
只要并发的多个执行单元存在对共享资源的访问，竞态就有可能发生。
如果中断处理程序访问进程正在访问的资源，则竞态也会会发生。
多个中断之间本身也可能引起并发而导致竞态（中断被更高优先级的中断打断）。

解决竞态问题的途径是保证对共享资源的互斥访问，所谓互斥访问就是指一个执行单元在访问共享资源的时候，其他的执行单元都被禁止访问。

访问共享资源的代码区域被称为临界区，临界区需要以某种互斥机制加以保护，中断屏蔽，原子操作，自旋锁，和信号量都是linux设备驱动中可采用的互斥途径。

临界区和竞争条件：
所谓临界区（critical regions）就是访问和操作共享数据的代码段，为了避免在临界区中并发访问，编程者必须保证这些代码原子地执行——也就是说，代码在执行结束前不可被打断，就如同整个临界区是一个不可分割的指令一样，如果两个执行线程有可能处于同一个临界区中，那么就是程序包含一个bug，如果这种情况发生了，我们就称之为竞争条件（race conditions），避免并发和防止竞争条件被称为同步。

死锁：
死锁的产生需要一定条件：要有一个或多个执行线程和一个或多个资源，每个线程都在等待其中的一个资源，但所有的资源都已经被占用了，所有线程都在相互等待，但它们永远不会释放已经占有的资源，于是任何线程都无法继续，这便意味着死锁的发生。

二、中断屏蔽
在单CPU范围内避免竞态的一种简单方法是在进入临界区之前屏蔽系统的中断。
由于linux内核的进程调度等操作都依赖中断来实现，内核抢占进程之间的并发也就得以避免了。
中断屏蔽的使用方法：
local_irq_disable()//屏蔽中断
//临界区
local_irq_enable()//开中断
特点：
由于linux系统的异步IO，进程调度等很多重要操作都依赖于中断，在屏蔽中断期间所有的中断都无法得到处理，因此长时间的屏蔽是很危险的，有可能造成数据丢失甚至系统崩溃，这就要求在屏蔽中断之后，当前的内核执行路径应当尽快地执行完临界区的代码。
中断屏蔽只能禁止本CPU内的中断，因此，并不能解决多CPU引发的竞态，所以单独使用中断屏蔽并不是一个值得推荐的避免竞态的方法，它一般和自旋锁配合使用。

三、原子操作
定义：原子操作指的是在执行过程中不会被别的代码路径所中断的操作。
（原子原本指的是不可分割的微粒，所以原子操作也就是不能够被分割的指令）
（它保证指令以“原子”的方式执行而不能被打断）
原子操作是不可分割的，在执行完毕不会被任何其它任务或事件中断。在单处理器系统(UniProcessor)中，能够在单条指令中完成的操作都可以认为是" 原子操作"，因为中断只能发生于指令之间。这也是某些CPU指令系统中引入了test_and_set、test_and_clear等指令用于临界资源互斥的原因。但是，在对称多处理器(Symmetric Multi-Processor)结构中就不同了，由于系统中有多个处理器在独立地运行，即使能在单条指令中完成的操作也有可能受到干扰。我们以decl (递减指令)为例，这是一个典型的"读－改－写"过程，涉及两次内存访问。
通俗理解：
原子操作，顾名思义，就是说像原子一样不可再细分。一个操作是原子操作，意思就是说这个操作是以原子的方式被执行，要一口气执行完，执行过程不能够被OS的其他行为打断，是一个整体的过程，在其执行过程中，OS的其它行为是插不进来的。
分类：linux内核提供了一系列函数来实现内核中的原子操作，分为整型原子操作和位原子操作，共同点是：在任何情况下操作都是原子的，内核代码可以安全的调用它们而不被打断。

原子整数操作：
针对整数的原子操作只能对atomic_t类型的数据进行处理，在这里之所以引入了一个特殊的数据类型，而没有直接使用C语言的int型，主要是出于两个原因：
第一、让原子函数只接受atomic_t类型的操作数，可以确保原子操作只与这种特殊类型数据一起使用，同时，这也确保了该类型的数据不会被传递给其它任何非原子函数；
第二、使用atomic_t类型确保编译器不对相应的值进行访问优化——这点使得原子操作最终接收到正确的内存地址，而不是一个别名，最后就是在不同体系结构上实现原子操作的时候，使用atomic_t可以屏蔽其间的差异。
原子整数操作最常见的用途就是实现计数器。
另一点需要说明原子操作只能保证操作是原子的，要么完成，要么不完成，不会有操作一半的可能，但原子操作并不能保证操作的顺序性，即它不能保证两个操作是按某个顺序完成的。如果要保证原子操作的顺序性，请使用内存屏障指令。
atomic_t和ATOMIC_INIT(i)定义
typedef struct { volatile int counter; } atomic_t;
#define ATOMIC_INIT(i) { (i) }

在你编写代码的时候，能使用原子操作的时候，就尽量不要使用复杂的加锁机制，对多数体系结构来讲，原子操作与更复杂的同步方法相比较，给系统带来的开销小，对高速缓存行的影响也小，但是，对于那些有高性能要求的代码，对多种同步方法进行测试比较，不失为一种明智的作法。

原子位操作：
针对位这一级数据进行操作的函数，是对普通的内存地址进行操作的。它的参数是一个指针和一个位号。

为方便其间，内核还提供了一组与上述操作对应的非原子位函数，非原子位函数与原子位函数的操作完全相同，但是，前者不保证原子性，且其名字前缀多两个下划线。例如，与test_bit()对应的非原子形式是_test_bit()，如果你不需要原子性操作（比如，如果你已经用锁保护了自己的数据），那么这些非原子的位函数相比原子的位函数可能会执行得更快些。

四、自旋锁
自旋锁的引入：
如 果每个临界区都能像增加变量这样简单就好了，可惜现实不是这样，而是临界区可以跨越多个函数，例如：先得从一个数据结果中移出数据，对其进行格式转换和解 析，最后再把它加入到另一个数据结构中，整个执行过程必须是原子的，在数据被更新完毕之前，不能有其他代码读取这些数据，显然，简单的原子操作是无能为力 的（在单处理器系统(UniProcessor)中，能够在单条指令中完成的操作都可以认为是" 原子操作"，因为中断只能发生于指令之间），这就需要使用更为复杂的同步方法——锁来提供保护。

自旋锁的介绍：
Linux内核中最常见的锁是自旋锁（spin lock），自旋锁最多只能被一个可执行线程持有，如果一个执行线程试图获得一个被争用（已经被持有）的自旋锁，那么该线程就会一直进行忙循环—旋转—等待锁重新可用，要是锁未被争用，请求锁的执行线程便能立刻得到它，继续执行，在任意时间，自旋锁都可以防止多于一个的执行线程同时进入理解区，注意同一个锁可以用在多个位置—例如，对于给定数据的所有访问都可以得到保护和同步。
一个被争用的自旋锁使得请求它的线程在等待锁重新可用时自旋（特别浪费处理器时间），所以自旋锁不应该被长时间持有，事实上，这点正是使用自旋锁的初衷，在短期间内进行轻量级加锁，还可以采取另外的方式来处理对锁的争用：让请求线程睡眠，直到锁重新可用时再唤醒它，这样处理器就不必循环等待，可以去执行其他代码，这也会带来一定的开销——这里有两次明显的上下文切换， 被阻塞的线程要换出和换入。因此，持有自旋锁的时间最好小于完成两次上下文切换的耗时，当然我们大多数人不会无聊到去测量上下文切换的耗时，所以我们让持 有自旋锁的时间应尽可能的短就可以了，信号量可以提供上述第二种机制，它使得在发生争用时，等待的线程能投入睡眠，而不是旋转。
自旋锁可以使用在中断处理程序中（此处不能使用信号量，因为它们会导致睡眠），在中断处理程序中使用自旋锁时，一定要在获取锁之前，首先禁止本地中断（在 当前处理器上的中断请求），否则，中断处理程序就会打断正持有锁的内核代码，有可能会试图去争用这个已经持有的自旋锁，这样以来，中断处理程序就会自旋， 等待该锁重新可用，但是锁的持有者在这个中断处理程序执行完毕前不可能运行，这正是我们在前一章节中提到的双重请求死锁，注意，需要关闭的只是当前处理器上的中断，如果中断发生在不同的处理器上，即使中断处理程序在同一锁上自旋，也不会妨碍锁的持有者（在不同处理器上）最终释放锁。

自旋锁的简单理解：
理解自旋锁最简单的方法是把它作为一个变量看待，该变量把一个临界区或者标记为“我当前正在运行，请稍等一会”或者标记为“我当前不在运行，可以被使用”。如果A执行单元首先进入例程，它将持有自旋锁，当B执行单元试图进入同一个例程时，将获知自旋锁已被持有，需等到A执行单元释放后才能进入。

自旋锁的API函数：

其实介绍的几种信号量和互斥机制，其底层源码都是使用自旋锁,可以理解为自旋锁的再包装。所以从这里就可以理解为什么自旋锁通常可以提供比信号量更高的性能。
自旋锁是一个互斥设备，他只能会两个值：“锁定”和“解锁”。它通常实现为某个整数之中的单个位。
“测试并设置”的操作必须以原子方式完成。
任何时候，只要内核代码拥有自旋锁，在相关CPU上的抢占就会被禁止。
适用于自旋锁的核心规则：
（1）任何拥有自旋锁的代码都必须使原子的，除服务中断外（某些情况下也不能放弃CPU,如中断服务也要获得自旋锁。为了避免这种锁陷阱，需要在拥有自旋锁时禁止中断），不能放弃CPU（如休眠，休眠可发生在许多无法预期的地方）。否则CPU将有可能永远自旋下去（死机）。
（2）拥有自旋锁的时间越短越好。

需 要强调的是，自旋锁别设计用于多处理器的同步机制，对于单处理器（对于单处理器并且不可抢占的内核来说，自旋锁什么也不作），内核在编译时不会引入自旋锁 机制，对于可抢占的内核，它仅仅被用于设置内核的抢占机制是否开启的一个开关，也就是说加锁和解锁实际变成了禁止或开启内核抢占功能。如果内核不支持抢 占，那么自旋锁根本就不会编译到内核中。
内核中使用spinlock_t类型来表示自旋锁，它定义在：
typedef struct {
raw_spinlock_t raw_lock;
#if defined(CONFIG_PREEMPT) && defined(CONFIG_SMP)
unsigned int break_lock;
#endif
} spinlock_t;

对于不支持SMP的内核来说，struct raw_spinlock_t什么也没有，是一个空结构。对于支持多处理器的内核来说，struct raw_spinlock_t定义为
typedef struct {
unsigned int slock;
} raw_spinlock_t;

slock表示了自旋锁的状态，“1”表示自旋锁处于解锁状态（UNLOCK），“0”表示自旋锁处于上锁状态（LOCKED）。
break_lock表示当前是否由进程在等待自旋锁，显然，它只有在支持抢占的SMP内核上才起作用。
自旋锁的实现是一个复杂的过程，说它复杂不是因为需要多少代码或逻辑来实现它，其实它的实现代码很少。自旋锁的实现跟体系结构关系密切，核心代码基本也是由汇编语言写成，与体协结构相关的核心代码都放在相关的目录下，比如。对于我们驱动程序开发人员来说，我们没有必要了解这么spinlock的内部细节，如果你对它感兴趣，请参考阅读Linux内核源代码。对于我们驱动的spinlock接口，我们只需包括头文件。在我们详细的介绍spinlock的API之前，我们先来看看自旋锁的一个基本使用格式：
#include
spinlock_t lock = SPIN_LOCK_UNLOCKED;

spin_lock(&lock);
....
spin_unlock(&lock);

从使用上来说，spinlock的API还很简单的，一般我们会用的的API如下表，其实它们都是定义在中的宏接口，真正的实现在中
#include
SPIN_LOCK_UNLOCKED
DEFINE_SPINLOCK
spin_lock_init( spinlock_t *)
spin_lock(spinlock_t *)
spin_unlock(spinlock_t *)
spin_lock_irq(spinlock_t *)
spin_unlock_irq(spinlock_t *)
spin_lock_irqsace(spinlock_t *，unsigned long flags)
spin_unlock_irqsace(spinlock_t *, unsigned long flags)
spin_trylock(spinlock_t *)
spin_is_locked(spinlock_t *)

• 初始化
spinlock有两种初始化形式，一种是静态初始化，一种是动态初始化。对于静态的spinlock对象，我们用 SPIN_LOCK_UNLOCKED来初始化，它是一个宏。当然，我们也可以把声明spinlock和初始化它放在一起做，这就是 DEFINE_SPINLOCK宏的工作，因此，下面的两行代码是等价的。
DEFINE_SPINLOCK (lock);
spinlock_t lock = SPIN_LOCK_UNLOCKED;

spin_lock_init 函数一般用来初始化动态创建的spinlock_t对象，它的参数是一个指向spinlock_t对象的指针。当然，它也可以初始化一个静态的没有初始化的spinlock_t对象。
spinlock_t *lock
......
spin_lock_init(lock);

• 获取锁
内核提供了三个函数用于获取一个自旋锁。
spin_lock：获取指定的自旋锁。
spin_lock_irq：禁止本地中断并获取自旋锁。
spin_lock_irqsace：保存本地中断状态，禁止本地中断并获取自旋锁，返回本地中断状态。

自旋锁是可以使用在中断处理程序中的，这时需要使用具有关闭本地中断功能的函数，我们推荐使用 spin_lock_irqsave，因为它会保存加锁前的中断标志，这样就会正确恢复解锁时的中断标志。如果spin_lock_irq在加锁时中断是关闭的，那么在解锁时就会错误的开启中断。

另外两个同自旋锁获取相关的函数是：
spin_trylock()：尝试获取自旋锁，如果获取失败则立即返回非0值，否则返回0。
spin_is_locked()：判断指定的自旋锁是否已经被获取了。如果是则返回非0，否则，返回0。
• 释放锁
同获取锁相对应，内核提供了三个相对的函数来释放自旋锁。
spin_unlock：释放指定的自旋锁。
spin_unlock_irq：释放自旋锁并激活本地中断。
spin_unlock_irqsave：释放自旋锁，并恢复保存的本地中断状态。

五、读写自旋锁
如 果临界区保护的数据是可读可写的，那么只要没有写操作，对于读是可以支持并发操作的。对于这种只要求写操作是互斥的需求，如果还是使用自旋锁显然是无法满 足这个要求（对于读操作实在是太浪费了）。为此内核提供了另一种锁－读写自旋锁，读自旋锁也叫共享自旋锁，写自旋锁也叫排他自旋锁。
读写自旋锁是一种比自旋锁粒度更小的锁机制，它保留了“自旋”的概念，但是在写操作方面，只能最多有一个写进程，在读操作方面，同时可以有多个读执行单元，当然，读和写也不能同时进行。
读写自旋锁的使用也普通自旋锁的使用很类似，首先要初始化读写自旋锁对象：
// 静态初始化
rwlock_t rwlock = RW_LOCK_UNLOCKED;
//动态初始化
rwlock_t *rwlock;
...
rw_lock_init(rwlock);

在读操作代码里对共享数据获取读自旋锁：
read_lock(&rwlock);
...
read_unlock(&rwlock);

在写操作代码里为共享数据获取写自旋锁：
write_lock(&rwlock);
...
write_unlock(&rwlock);

需要注意的是，如果有大量的写操作，会使写操作自旋在写自旋锁上而处于写饥饿状态（等待读自旋锁的全部释放），因为读自旋锁会自由的获取读自旋锁。

读写自旋锁的函数类似于普通自旋锁，这里就不一一介绍了，我们把它列在下面的表中。
RW_LOCK_UNLOCKED
rw_lock_init(rwlock_t *)
read_lock(rwlock_t *)
read_unlock(rwlock_t *)
read_lock_irq(rwlock_t *)
read_unlock_irq(rwlock_t *)
read_lock_irqsave(rwlock_t *, unsigned long)
read_unlock_irqsave(rwlock_t *, unsigned long)
write_lock(rwlock_t *)
write_unlock(rwlock_t *)
write_lock_irq(rwlock_t *)
write_unlock_irq(rwlock_t *)
write_lock_irqsave(rwlock_t *, unsigned long)
write_unlock_irqsave(rwlock_t *, unsigned long)
rw_is_locked(rwlock_t *)
六、顺序琐
顺序琐（seqlock）是对读写锁的一种优化，若使用顺序琐，读执行单元绝不会被写执行单元阻塞，也就是说，读执行单元可以在写执行单元对被顺序琐保护的共享资源进行写操作时仍然可以继续读，而不必等待写执行单元完成写操作，写执行单元也不需要等待所有读执行单元完成读操作才去进行写操作。
但是，写执行单元与写执行单元之间仍然是互斥的，即如果有写执行单元在进行写操作，其它写执行单元必须自旋在哪里，直到写执行单元释放了顺序琐。
如果读执行单元在读操作期间，写执行单元已经发生了写操作，那么，读执行单元必须重新读取数据，以便确保得到的数据是完整的，这种锁在读写同时进行的概率比较小时，性能是非常好的，而且它允许读写同时进行，因而更大的提高了并发性，
注意，顺序琐由一个限制，就是它必须被保护的共享资源不含有指针，因为写执行单元可能使得指针失效，但读执行单元如果正要访问该指针，将导致Oops。
七、信号量
Linux中的信号量是一种睡眠锁，如果有一个任务试图获得一个已经被占用的信号量时，信号量会将其推进一个等待队列，然后让其睡眠，这时处理器能重获自由，从而去执行其它代码，当持有信号量的进程将信号量释放后，处于等待队列中的哪个任务被唤醒，并获得该信号量。
信号量，或旗标，就是我们在操作系统里学习的经典的P/V原语操作。
P：如果信号量值大于0，则递减信号量的值，程序继续执行，否则，睡眠等待信号量大于0。
V：递增信号量的值，如果递增的信号量的值大于0，则唤醒等待的进程。

信号量的值确定了同时可以有多少个进程可以同时进入临界区，如果信号量的初始值始1，这信号量就是互斥信号量（MUTEX）。对于大于1的非0值信号量，也可称为计数信号量（counting semaphore）。对于一般的驱动程序使用的信号量都是互斥信号量。
类似于自旋锁，信号量的实现也与体系结构密切相关，具体的实现定义在头文件中，对于x86_32系统来说，它的定义如下：
struct semaphore {
atomic_t count;
int sleepers;
wait_queue_head_t wait;
};

信号量的初始值count是atomic_t类型的，这是一个原子操作类型，它也是一个内核同步技术，可见信号量是基于原子操作的。我们会在后面原子操作部分对原子操作做详细介绍。

信号量的使用类似于自旋锁，包括创建、获取和释放。我们还是来先展示信号量的基本使用形式：
static DECLARE_MUTEX(my_sem);
......
if (down_interruptible(&my_sem))

{
return -ERESTARTSYS;
}
......
up(&my_sem)

Linux内核中的信号量函数接口如下：
static DECLARE_SEMAPHORE_GENERIC(name, count);
static DECLARE_MUTEX(name);
seam_init(struct semaphore *, int);
init_MUTEX(struct semaphore *);
init_MUTEX_LOCKED(struct semaphore *)
down_interruptible(struct semaphore *);
down(struct semaphore *)
down_trylock(struct semaphore *)
up(struct semaphore *)
• 初始化信号量
信号量的初始化包括静态初始化和动态初始化。静态初始化用于静态的声明并初始化信号量。
static DECLARE_SEMAPHORE_GENERIC(name, count);
static DECLARE_MUTEX(name);

对于动态声明或创建的信号量，可以使用如下函数进行初始化：
seam_init(sem, count);
init_MUTEX(sem);
init_MUTEX_LOCKED(struct semaphore *)

显然，带有MUTEX的函数始初始化互斥信号量。LOCKED则初始化信号量为锁状态。
• 使用信号量
信号量初始化完成后我们就可以使用它了
down_interruptible(struct semaphore *);
down(struct semaphore *)
down_trylock(struct semaphore *)
up(struct semaphore *)

down函数会尝试获取指定的信号量，如果信号量已经被使用了，则进程进入不可中断的睡眠状态。down_interruptible则会使进程进入可中断的睡眠状态。关于进程状态的详细细节，我们在内核的进程管理里在做详细介绍。

down_trylock尝试获取信号量， 如果获取成功则返回0，失败则会立即返回非0。

当退出临界区时使用up函数释放信号量，如果信号量上的睡眠队列不为空，则唤醒其中一个等待进程。

八、读写信号量
类似于自旋锁，信号量也有读写信号量。读写信号量API定义在头文件中，它的定义其实也是体系结构相关的，因此具体实现定义在头文件中，以下是x86的例子：
struct rw_semaphore {
signed long count;
spinlock_t wait_lock;
struct list_head wait_list;
};

㈨ 为什么说LINUX 内核调度的是线程，而不是进程呢 难道内核中进程是不切换，只切换线程

貌似不对哦，在LINUX系统之中，被调度的应该是进程。因为只有进程才拥有一个独立的上下文环境，是分配系统资源的最小单位……而线程在SMP体系中加速了执行的效率……
在LINUX之中，线程也可称作轻量级进程，它能享有自己的堆栈，线程ID等独立资源，但大多还是要依赖其创建进程，比如地址空间，信号，文件句柄……