任务调度，轮询任务调度和抢占式任务调度的区别

1，轮询任务调度和抢占式任务调度的区别

抢占式与非抢占式的对比：非抢占式（Nonpreemptive）让进程运行直到结束或阻塞的调度方式容易实现适合专用系统，不适合通用系统抢占式（Preemptive）允许将逻辑上可继续运行的在运行过程暂停的调度方式可防止单一进程长时间独占CPU 系统开销大（降低途径：硬件实现进程切换，或扩充主存以贮存大部分程序）

轮询任务调度和抢占式任务调度的区别

2，uCOSII的任务调度

uC/OS-II 采用的是可剥夺型实时多任务内核。可剥夺型的实时内核在任何时候都运行就绪了的最高优先级的任务。uC/os-II的任务调度是完全基于任务优先级的抢占式调度，也就是最高优先级的任务一旦处于就绪状态，则立即抢占正在运行的低优先级任务的处理器资源。为了简化系统设计，uC/OS-II规定所有任务的优先级不同，因为任务的优先级也同时唯一标志了该任务本身。1）高优先级的任务因为需要某种临界资源，主动请求挂起，让出处理器，此时将调度就绪状态的低优先级任务获得执行，这种调度也称为任务级的上下文切换。2）高优先级的任务因为时钟节拍到来，在时钟中断的处理程序中，内核发现高优先级任务获得了执行条件(如休眠的时钟到时)，则在中断态直接切换到高优先级任务执行。这种调度也称为中断级的上下文切换。这两种调度方式在uC/OS-II的执行过程中非常普遍，一般来说前者发生在系统服务中，后者发生在时钟中断的服务程序中。调度工作的内容可以分为两部分：最高优先级任务的寻找和任务切换。其最高优先级任务的寻找是通过建立就绪任务表来实现的。u C / O S 中的每一个任务都有独立的堆栈空间，并有一个称为任务控制块TCB(Task Control Block)的数据结构，其中第一个成员变量就是保存的任务堆栈指针。任务调度模块首先用变量OSTCBHighRdy 记录当前最高级就绪任务的TCB 地址，然后调用OS_TASK_SW()函数来进行任务切换。

uCOSII的任务调度

3，关于ucos任务调度的问题嵌入式高手进

从内核角度讲：简化的（忽略一些细节），UCOS启动时会创建一个idle的任务，这个任务是最低优先级的，且不会被删除。调用OSTaskCreate可以创建新的任务，系统维护了一个任务列表（TCB）。任务有休眠（可以理解成已经被从任务列表中删除的任务），等待，Ready，运行 4种状态（书上不是这么说的，但可以这么理解，等待状态可能有多种原因造成）系统在中断处理函数中执行任务调度过程，执行优先级最高的，处于ready状态的任务。调度成功后此任务从ready变成运行状态。如果没有任何任务可以调度，那么idle这个任务就会运行。从编程角度讲： 1. 硬件中断产生会导致调度，例如I/O中断，这个不需要细说。 2. 在当前任务中调用OSTaskCreae创建新任务，会导致一个系统的内核调用，会产生一个模拟中断，因为系统在中断处理时执行任务调度，所以如果新任务的优先级比当前的大，新任务会立刻被运行。 3. 调用OSStart会导致一个系统的内核调用，会产生一个模拟中断，因为系统在中断处理时执行任务调度，所以优先级最高的，处于ready状态的任务会被执行。 4. 调用OSTimeDly可以将当前任务改成等待状态，设置等待的时间，然后会导致一个系统的内核调用，会产生一个模拟中断。所以另一个优先级最高的，处于ready状态的任务会被执行；在系统的时钟中断中会在等待时间到了之后把任务改成ready状态。 5. OSSemPend、OSMboxPend，OSQPend等函数调用也会导致当前任务改成等待状态，然后会导致一个系统的内核调用，会产生一个模拟中断。所以另一个优先级最高的，处于ready状态的任务会被执行；这个等待状态必须在收到wakeup的信号才能解除。 6. 修改任务优先级也可以引起调度。实际的硬件中断对应的系统调度函数是OSIntExt，其他软件模拟调度的函数是OSSched。 UCOS的调度原理总体来说非常简单，因为没有时间片概念和优先级反转的问题。 UCOS有很多优化或者定制版本，大多在调度上会有自己的修改，请注意。

关于ucos任务调度的问题嵌入式高手进

4，求助Linux下任务调度

你把你的裸机程序当作是单个程序来看，如果涉及到硬件操作那就相对复杂好多了（估计你要问的是这个吧？），LINUX不太允许你直接在应用层操作底层的东西。LINUX就把你这个单个程序进行执行。像说所说的这种分时间片的任务调度，如果单单是不涉及硬件，完全可以把它写在单个应用程序上，然后进行编译运行。如果涉及到一些硬件的操作，不妨通过加载一层底层的驱动，把相关的寄存器remap到应用层上，这样用户程序就可以操作了。这是其中一个思路吧。这是裸机和LINUX的最大区别之一。

回复你这样一种情况就把你单片机的整个任务调度写成一个多线程，一旦写成这个样子（单个程序，其实就是单个程序），LINUX就会对它进行调度。而LINUX中的调度和你改写成单程序后的调度是不同的两个东西，LINUX的调度是在程序与程序之间，而你改写后的是一个多线程的东西，是线程和线程的切换，由LINUX进行管理，不需要你去考虑。而你所说的有足够时间去等待一些数据，这可以通过NEW几个线程，各个线程分配各自的功能模块（相当于是你裸机下的任务），它们之间是通过相关的信号量来进行通讯的。这样完全可以改写。而且改写的时候不需要考虑切换的东西，只需要考虑上层的东西。例如：线程1：等待N个数据，线程2：从硬件接收N个数据。这时，线程1如果没有接收到数据的话，则由LINUX自动管理去休眠线程2从硬件收到N个数据，由LINUX发送给正在等待的线程这就是你裸机下所做的任务了吧？

1）第一个问题归结于时钟（可软可硬）和进程之间的通讯2）不会超过多少时间看你写的怎么样吧（你不要for()100000000000000000000这么多次就可以了），还有中断不会多就1000%都可以3）这个不用担心，操作系统执行完你所说的任务，就不管，肯定有时间去做其它的事情。

回复硬件操作都通过设备驱动，驱动程序涉及I2C，UART，定时器，什么的，象I2C，UART这些都是私有协议，驱动搞好以后，加载到内核，应用程序操作硬件不也是和文件操作一样，open，什么的，用这些驱动（/dev下），那些任务调度通过多线程或者什么实现，是不是移植到Linux系统中，不用考虑裸机下任务调度的问题，还是比裸机任务调度要方便。--回复我现在的任务调度情况是这样的：有20个任务需要在1s内按顺序执行，并且每两个任务之间有空闲时间来接收UART的数据并处理任务,这样一种任务调度。在Linux中任务调度怎样处理，是不是用多线程来处理，还是定时器什么的。

回复谢谢你呀。

回复 1）这20个任务在1s内必须且只能执行一次，并且是按顺序执行的。如在1s内先执行了任务1、才能执行任务2。。。。 2）当让每个任务不会超过20ms的执行时间； 3）在每两个任务之间都需要有时间来处理串口的数据。

5，linux的任务调度机制是什么

调度程序运行时，要在所有可运行状态的进程中选择最值得运行的进程投入运行。选择进程的依据是什么呢？在每个进程的task_struct结构中有以下四项：policy、priority、counter、rt_priority。这四项是选择进程的依据。其中，policy是进程的调度策略，用来区分实时进程和普通进程，实时进程优先于普通进程运行；priority是进程(包括实时和普通)的静态优先级；counter是进程剩余的时间片，它的起始值就是priority的值；由于counter在后面计算一个处于可运行状态的进程值得运行的程度goodness时起重要作用，因此，counter 也可以看作是进程的动态优先级。rt_priority是实时进程特有的，用于实时进程间的选择。 Linux用函数goodness()来衡量一个处于可运行状态的进程值得运行的程度。该函数综合了以上提到的四项，还结合了一些其他的因素，给每个处于可运行状态的进程赋予一个权值(weight)，调度程序以这个权值作为选择进程的唯一依据。关于goodness()的情况在后面将会详细分析。

进程调度策略就是调度系统种哪一个进程来cpu运行。这种调度分2层考虑。第一层，进程状态这个是最优先考虑的，也就是说优先级最高的。在linux中只有就绪态的进程才有可能会被调度选中然后占有cpu，其它状态的进程不可能占有的到cpu。下面是linux中进程的状态 task_running:就绪状态，得到cpu就可以运行。task_interruptible:浅度睡眠，资源到位或者受到信号就会变成就绪态。task_uninterruptible:深度睡眠，资源到位就会进入就绪态，不响应信号。task_zombie：僵死态，进程exit后。task_stopped：暂停态，收到sig_cont信号进入就绪态。第二层，其实真正在操作系统中的实现，就是所有就绪态进程链接成一个队列，进程调度时候只会考虑这个队列中的进程，对其它的进程不考虑，这就实现了第一层中的要求。接下来就是就绪队列内部各个进程的竞争了。 linux采用3种不同的调度政策，sched_fifo（下面简写成fifo，先来先服务），sched_rr（简写成rr，时间片轮流），sched_other（下面简写成other）。这里大家就能看出一个问题，采用同等调度政策的进程之间自然有可比性，linux3种调度政策并存，那么不同调度政策间的进程如何比较呢？可以说他们之间根本就没有可比性。其实在调度时候，调度只看一个指标，那就是各个进程所具有的权值，权值最大的且在可执行队列中排在最前面的就会被调度执行。而权值的计算才会设计到各方面因素，其中调度政策可以说在计算权值中，份量是最重的。为什么linux要这么干呢？这是由于事务的多样性决定的，进程有实时性进程和非实时性的进程2种，fifo和rr是用来支持实时性进程的调度，我们看一下这3种政策下权值的计算公式就明白了： fifo和rr计算公式，权值=1000+进程真正的运行时间 other计算公式，当时间片为0时，权值=0.当时间片不为0时候，权值=剩余时间片+20-nice,同时如果是内核线程有+1的小加分，这是因为内核线程无需用户空间的切换，所以给它加了一分，奖励他在进程切换时候开销小的功劳。时间片好理解，那么nice这个值，用过linux系统的人都知道，这是一个从unix下继承过来的概念，表示谦让度，是一个从20～-19的数，可以通过nice和renice指令来设置。从代码中也能看到值越小就越不会谦让他人。从这里我们看出fifo和rr至少有1000的基数，所以在有fifo和rr调度政策进程存在时，other进程是没有机会被调度的到的。从权值计算公式同时也能看出，fifo先来先服务的调度政策满足了，但rr这个时间片轮流的调度如果按照这种权值计算是不能满足时间片轮流这一概念的。这里只是权值的计算，在调度时候对rr政策的进程特殊处理。以上都是权值计算，下面看看真正的调度过程，首先是对rr政策进程的特殊处理，如果当前进程采用的rr政策，那么看他的时间片是否用完，用完了就踢到就绪队列尾部，同时恢复他的时间片。然后是便利整个就绪队列，找到第一个权值最大的进程来运行。整体调度效果就是：如果有fifo和rr政策的进程，就优先调度他们2个，他们之间看已执行时间长短决定胜负，而2种政策内部则遵守各自调度政策。而other只有在前面2种不存在于就绪队列时候才有可能执行，他们实际也是轮流执行，但他们之间是靠剩余时间和nice值来决定胜负。同时就绪队列中排在最前面的最优先考虑在同样权值情况下。

6，怎么优化hadoop任务调度算法

为了提高reduce阶段的并行度，terasort作业对以上算法进行改进：在map阶段，每个map task都会将数据划分成r个数据块（r为reduce task个数）其中第i（i>0）个数据块的所有数据都会比第i+1个中的数据大；在reduce阶段，第i个reduce task处理（进行排序）所有map task的第i块，这样第i个reduce task产生的结果均会比第i+1个大，最后将1~r个reduce task的排序结果顺序输出，即为最终的排序结果。

首先介绍了Hadoop平台下作业的分布式运行机制，然后对Hadoop平台自带的4种任务调度器做分析和比较，最后在分析JobTracker类文件的基础上指出了创建自定义任务调度器所需完成的工作。首先Hadoop集群式基于单服务器的，只有一个服务器节点负责调度整个集群的作业运行，主要的具体工作是切分大数据量的作业，指定哪些Worker节点做Map工作、哪些Worker节点做Reduce工作、与Worker节点通信并接受其心跳信号、作为用户的访问入口等等。其次，集群中的每个Worker节点相当于一个器官，运行着主节点所指派的具体作业。这些节点会被分为两种类型，一种是接收分块之后的作业并做映射工作。另一种是负责把前面所做的映射工作按照约定的规则做一个统计。Task－Tracker通过运行一个简单循环来定期地发送心跳信号（heartbeat）给JobTracker．这个心跳信号会把TaskTracker是否还在存活告知JobTracker，TaskTracker通过信号指明自己是否已经准备好运行新的任务．一旦TaskTracker已经准备好接受任务，JobTracker就会从作业优先级表中选定一个作业并分配下去．至于到底是执行Map任务还是Reduce任务，是由TaskTracker的任务槽所决定的．默认的任务调度器在处理Reduce任务之前，会优先填满空闲的Map任务槽．因此，如果TaskTracker满足存在至少一个空闲任务槽时，JobTracker会为它分配Map任务，否则为它选择一个Reduce任务．TaskTracker在运行任务的时候，第一步是从共享文件系统中把作业的JAR文件复制过来，从而实现任务文件的本地化．第二步是TaskTracker为任务新建一个本地文件夹并把作业文件解压在此目录中．第三步是由Task－Tracker新建一个TaskRunner实例来运行该任务．Hadoop平台默认的调度方案就是JobQueueTaskScheduler，这是一种按照任务到来的时间先后顺序而执行的调度策略．这种方式比较简单，JobTracker作为主控节点，仅仅是依照作业到来的先后顺序而选择将要执行的作业．当然，这有一定的缺陷，由于Hadoop平台是默认将作业运行在整个集群上的，那么如果一个耗时非常大的作业进入执行期，将会导致其余大量作业长时间得不到运行．这种长时间运行的优先级别并不高的作业带来了严重的作业阻塞，使得整个平台的运行效率处在较低的水平．Hadoop平台对这种FIFO（First　INAnd　First　Out）机制所给出的解决办法是调用SetJobPriority（）方法，通过设置作业的权重级别来做平衡调度．Fair　Scheduler是一种“公平”调度器，它的目标是让每个用户能够公平地共享Hadoop集群计算能力．当只有一个作业运行的时候，它会得到整个集群的资源．随着提交到作业表中作业的增多，Hadoop平台会把集群中空闲出来的时间槽公平分配给每个需要执行的作业．这样即便其中某些作业需要较长时间运行，平台仍然有能力让那些短作业在合理时间内完成［3］．Fair　Scheduler支持资源抢占，当一个资源池在一定时段内没有得到公平共享时，它会终止该资源池所获得的过多的资源，同时把这些释放的资源让给那些资源不足的资源池．Hadoop平台中的Capacity　Scheduler是由Yahoo贡献的，在调度器上，设置了三种粒度的对象：queue，job，task．在该策略下，平台可以有多个作业队列，每个作业队列经提交后，都会获得一定数量的TaskTracker资源．具体调度流程如下．（1）选择queue，根据资源库的使用情况从小到大排序，直到找到一个合适的job．（2）选择job，在当前所选定的queue中，按照作业提交的时间先后以及作业的权重优先级别进行排序，选择合适的job．当然，在job选择时还需要考虑所选作业是否超出目前现有的资源上限，以及资源池中的内存是否够该job的task用等因素．（3）选择task，根据本地节点的资源使用情况来选择合适的task．虽然Hadoop平台自带了几种调度器，但是上述3种调度方案很难满足公司复杂的应用需求．因此作为平台的个性化使用者，往往需要开发自己的调度器．Hadoop的调度器是在JobTracker中加载和调用的，因此开发一个自定义的调度器就必须搞清楚JobTracker类文件的内部机制．作为Hadoop平台的核心组件，JobTracker监控着整个集群的作业运行情况并对资源进行管理调度．每个Task－Tracker每隔3s通过heartbeat向JobTracker汇报自己管理的机器的一些基本信息，包括内存使用量、内存的剩余量以及空闲的slot数目等等［5］．一旦JobTracker发现了空闲slot，便会调用调度器中的AssignTask方法为该TaskTracker分配task。